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.
Testing is where we prepare the next stable release, the collection of packages
that work together.
The current autopkgtest gating has trouble finding the versions that are needed
to work together.
That's the situation I want to improve because it's been annoying me for too
long, and I need to do something about it instead waiting for others to do the
work.
"Being more liberal in pulling dependencies from unstable" sounds like
doing "just take the autopkgtest inside unstable for testing migration"
in a far more complicated way.
That's the far end of pulling dependencies from unstable, and not want I'm
considering.
This is what I'm currently considering implementing to improve the autopkgtest
gating:
Scenario: Source package (<candidate>) without transition wants to migrate
- Find all rdeps
- Find the subset of rdeps with autopkgtest
- If no newer version of the rdeps binary packages are in unstable, schedule
autopkgtest with src:<candidate> from unstable only
- If <rdep> has dependencies that are also rdeps of <candidate> and those have newer
version in unstable, schedule autopkgtest with src:<candidate> and src:<other-rdep> from
unstable
- If newer version of the deps binary packages are in unstable, schedule autopkgtest with
src:<candidate> and src:<rdep> from unstable
- If <rdep> has dependencies that are also rdeps of <candidate> and those have newer version in
unstable, schedule autopkgtest with src:<candidate>, src:<rdep>, and src:<other-rdep> from
unstable
Concrete example with gdal, grass, and gdal-grass:
candidate: gdal
- Find all rdeps
rdeps: ..., grass, ..., gdal-grass, ...
- Find the subset of rdeps with autopkgtest
subset: gdal-grass
- If no newer version of the rdeps binary packages are in unstable, schedule
autopkgtest with src:<candidate> from unstable only
pin: src:gdal
- If <rdep> has dependencies that are also rdeps of <candidate> and those have newer
version in unstable, schedule autopkgtest with src:<candidate> and src:<other-rdep> from
unstable
pin: src:gdal, src:grass
- If newer version of the deps binary packages are in unstable, schedule autopkgtest
with src:<candidate> and src:<rdep> from unstable
pin: src:gdal, src:gdal-grass
- If <rdep> has dependencies that are also rdeps of <candidate> and those have newer
version in unstable, schedule autopkgtest with src:<candidate>, src:<rdep>, and
src:<other-rdep> from unstable
pin: src:gdal, src:grass, src:gdal-grass
This should work for packages that get updated in unstable but don't trigger
transitions, and for those that do.
The fundamental question is really whether the runtime dependencies of
packages should ensure a functional setup.
Is that a rhetorical question?
There is more to autopkgtests than runtime dependencies, case in point the
autodep8 perl test for build 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.
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.
Kind Regards,
Bas
--
PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
