Package: psfex
Version: 3.24.2-2
Severity: serious

Hi,

The following fails:
- In bookworm, install psfex
- dist-upgrade to trixie
I would expect psfex to be upgraded, but it is not.

MWE:
PKG=psfex; mmdebstrap --chrooted-customize-hook="set -x ; apt -y install $PKG && sed -e s/bookworm/trixie/ -i /etc/apt/sources.list && apt update && apt dist-upgrade -y && apt dist-upgrade -y -o Debug::pkgProblemResolver=true" bookworm /dev/null

Relevant part:
Broken liblapacke:amd64 Breaks on libatlas3-base:amd64 < 3.10.3-13 @ii mK > (< 3.10.3-14)
Considering libatlas3-base:amd64 1 as a solution to liblapacke:amd64 0
Holding Back liblapacke:amd64 rather than change libatlas3-base:amd64 Investigating (0) psfex:amd64 < 3.21.1-1 -> 3.24.2-2 @ii umU Ib >
Broken psfex:amd64 Depends on liblapacke:amd64 < none | 3.12.1-2 @un uH > (>= 3.12.0)
Considering liblapacke:amd64 0 as a solution to psfex:amd64 0
Holding Back psfex:amd64 rather than change liblapacke:amd64
Try to Re-Instate (1) psfex:amd64
Done
Entering ResolveByKeep
The following packages were automatically installed and are no longer required:
libapt-pkg6.0 libargon2-1 libgnutls30 libquadmath0 libshp2 libtasn1-6 libunistring2
Use 'apt autoremove' to remove them.

Not upgrading:
psfex

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

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.

Do that mean making lapack break the -14 version is enough to fix this bug?
```
- libatlas3-base (<< 3.10.3-14)
+ libatlas3-base
```

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <[email protected]> [2025-07-18 10:26]:

Hi,

* M. Zhou <[email protected]> [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)

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" <[email protected]>:

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 <[email protected]> [2025-07-18 10:26]:

Hi,

* M. Zhou <[email protected]> [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)