On Wed, Dec 17, 2025 at 09:59:50PM +0100, Sebastiaan Couwenberg wrote: > On 12/17/25 8:57 PM, Adrian Bunk wrote: > > On Wed, Dec 17, 2025 at 07:12:32PM +0100, Sebastiaan Couwenberg wrote: > > > ... > > > Being more liberal in pulling dependencies from unstable in newer version > > > are available could be a solution too, I have a script [0] that get a > > > lists of dependencies that have newer versions in unstable. > > > ... > > > > Should Debian continue to support working upgrades, or should software > > only work within its suite? > > I don't think users can expect their system to work correctly when they > haven't upgraded all the packages.
Debian has a good reputation for working upgrades, even the libc5->libc6 migration was smooth. And plenty of things during an upgrade like service restarts and other postinst actions also rely on proper dependencies. >... > > An example: > > > > Due to #1122038 packages built in unstable had runtime dependencies that > > were fulfilled by libc6/testing despite actually requiring libc6/unstable > > for running. > > I think an autopkgtest running the executable on i386 would have caught this > issue, at least the job with libc6 from testing. > > That could have been a blocker for glibc testing migration. It was not a blocker for glibc testing migration, and it cannot be, since the new glibc worked with both the old and the new python3.13. > But that currently assumes that the package in question has a direct > dependency on libc6 and not via one of its dependencies, the autopkgtest > would likely not been scheduled without it being a direct rdep of libc6. > > Among the affected packages was src:python3.13, when you are "more > > liberal in pulling dependencies from unstable" in such a case you get > > green autopkgtests that migrate a Python interpreter that is non-working > > in testing. > Assuming the src:python3.13 autopkgtest fails on i386 because of this issue, > scheduling the CI job with src:python3.13 and src:glibc from unstable would > indicate that this combination is required if the result is success. > > So the autopkgtest succeeding should let src:glibc migrate only together with > src:python3.13. Scheduling the python3.13 autopkgtest with glibc/unstable would remove the blocker for python3.13 migration, it would not generate a migration dependency of python3.13 on glibc. And we really do not want such a migration-only dependency here, because if we do that testing users upgrading after the migration might get the python3.13 packages upgraded before the new libc6 has been unpacked, resulting in a system with a non-functional python where the remaining upgrade (including python3.13 postinst) will also fail. > Kind Regards, > > Bas cu Adrian
