Bug#1123074: release.debian.org: Help doxygen migrate to testing
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
Reply to: