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?
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 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.
I'm not sure how the autopkgtest gating should work to do want you want in this
scenario.
And I'm afraid it's out of scope for what I'm working in #1120799 and I won't
be able to make you happy with that.
Kind Regards,
Bas
--
PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
