On Thu, Dec 18, 2025 at 07:08:06AM +0100, Sebastiaan Couwenberg wrote: > On 12/17/25 11:30 PM, Adrian Bunk wrote: > > 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. > > How can autopkgtests help improve these scenarios?
By failing on non-working package combinations. That's how I discovered #1122038. Similar to the experimental pseudo-excuses, we could also run pseudo-excuses for testing->stable migration to match what people will experience during upgrades. This would need some blacklisting for test-only failures, but can cover a large area of potential upgrade issues. > > > > 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. > > #1122038 is about starpu, the job in question pulls only src:starpu from > unstable revealing the issue. The complete list of packages affected by #1122038 was in [1]. It was so short due to glibc having been uploaded shortly after buildd chroot rebuild, otherwise nearly every packages built during the time with the broken glibc would have been affected. > The CI jobs triggered by glibc/2.42-4 pull src:glibc and more from unstable > not exhibiting the issue. > > This is a scenario where starpu & glibc from unstable should migrate together. > > starpu from unstable not working with glibc from testing is not unexpected > when starpu from unstable was built with newer glibc from unstable. But this must be expressed in the package dependencies, to tell package managers that libc6 must be upgraded before starpu. Otherwise there might be a time during the upgrade where starpu is not functional. This might not be a huge issue for starpu, but with the also affected python3.13 it would be a disaster. > I'm not sure how the autopkgtest gating should work to do want you want in > this scenario. >... We want starpu fixed (as was done with [1]), not anything migration-only. Blocking starpu from migration (and NOT trying it together with the new glibc) is the best option for that. > Kind Regards, > > Bas cu Adrian [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121762#36
