Hi Jochen,
Ok. It looked like sort of miscommunication between online and offline.
Thanks for figuring out a working solution with offline folks.
The /var/lib/apt method is indeed a great way to experiment fixes.
And I confirm that Breaks+Replaces still does not resolving the issue.
I rethought about this. While the transitional package libatlas3-base
is not ideal and might break things in some corner cases, it is
at least working for the most cases to resolve the bug.
Let's move on with this since I cannot come up with a better working
solution given the current limitations of apt.
I'll handle the unblock and unstable upload.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109527
On Sat, 2025-07-19 at 19:21 +0200, Jochen Sprickerhof wrote:
Hi,
I talked to the apt maintainer and other experienced DDs at DebConf and we don't think it will work without a transition package in bookworm. Jilian said that it would work with apt from experimental but that's not an
option. Basically apt will sort keeping libatlas3-base installed over any other solution as long as there is no package with the same name in Trixie. You can try editing the Packages files in /var/lib/apt directly if you
want to test other solutions.
Feel free to take it from here.
Cheers Jochen
Am 19. Juli 2025 18:47:17 MESZ schrieb "M. Zhou" <lumin@debian.org>:
I disagree. You may have incorrectly understood the package
relationship here.
The binary package liblapacke is not a transitional package.
The latest liblapacke cannot provide what the old libatlas3-base
package provides. Instead, libatlas3-base is always a candidate
that may serve as a dependency of liblapacke. After some
point, libatlas3-base get removed, and hence existing packages
depending on libatlas3-base has to be built against the other
blas/lapack impelementations.
The original Breaks relationship is due to the underlying update-alternatives mechanism. We are sure liblapacke does
not work with libatlas3-base as the actual implementation.
The correct solution is to simply ask apt to get rid of
libatlas3-base. Please do not introduce a NEW binary package.
This is not transition. This is deprecation, which is
exactly Breaks+Repalces does.
Let me handle this bug. I'm co-maintainer of src:lapack.
On Sat, 2025-07-19 at 17:06 +0200, Jochen Sprickerhof wrote:
Hi,
I looked into it a bit more and got it working with a transitional dummy package as described here:
https://wiki.debian.org/RenamingPackages
I have added this to lapack:
Package: libatlas3-base
Depends: libblas3, ${misc:Depends}
Architecture: all
Priority: optional
Section: oldlibs
Description: transitional package
This is a transitional package. It can safely be removed.
As it is already late for trixie I uploaded it to NEW/experimental. The release team agreed to take it afterwards. I will take care of the rest unless someone disagrees with the approach.
Cheers Jochen
* Jochen Sprickerhof <jspricke@debian.org> [2025-07-18 10:26]:
Hi,
* M. Zhou <lumin@debian.org> [2025-07-17 22:35]:
I'm still a little bit confused about the report.
Based on the podman image debian:bookwork, I can upgrade psfex without apt
reporting issue like reported. So the problem seems to be highly specific
to the -14 revision of atlas.
There is a reproducer in the initial bug report that is still valid for me.
Do that mean making lapack break the -14 version is enough to fix this bug?
```
- libatlas3-base (<< 3.10.3-14)
+ libatlas3-base
```
From a quick look libatlas3-base in bookworm was split into multiple packages and there is a Break: but no Replaces: see
https://wiki.debian.org/PackageTransition
I think #7 applies.
Cheers Jochen
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)