On 12/18/25 10:05 PM, Paul Gevers wrote:
On 12/18/25 06:50, Sebastiaan Couwenberg wrote:
On 12/17/25 10:13 PM, Paul Gevers wrote:
On 12/17/25 19:12, Sebastiaan Couwenberg wrote:
I'm afraid that a proper solution requires access to d/t/control of the source
packages, are you aware what makes that difficult to make available?
I don't know, but I can imaging we don't want all the sources there if all we
need is d/t/control files.
I personally would like the test dependencies to move from d/t/control to
Test-Depends in d/control (and be available in Sources alongside
Build-Depends*), but then you lose the granularity per test.
I don't understand why this would help. Wouldn't that result in the same
content as Testsuite-Triggers.
Testsuite-Triggers is not present for packages using autodep8 as mentioned
before.
Having all dependencies in the same file makes it easier to keep them in sync
from a maintainer POV. Having Test-Depends available in Sources makes sense
from the POV of someone parsing all dependency types who also doesn't have to
access more than one file.
d/t/control made sense to when autopkgtest was introduced to keep everything
self contained, but having a second file now with test dependencies is wart to
shows this was bolted on later.
If not, what would be different (we can ask the dpkg maintainers to add the
thing you're missing). Related and maybe it can scratch a part of your itch:
are you aware of the hint-testsuite-triggers [1] restriction?
I was not aware of the hint-testsuite-triggers documentation, but having read
it its value is still not clear to me.
And it raises questions one how that interacts with <!nocheck> Build- Depends.
It would be ignored for builds I assume? ... Or do you want to *move* all "Build-Depends:
x <!nocheck>" binaries to the new field? Then how to distinguish build time test
dependencies from autopkgtest test dependencies?
I don't have answers to these questions yet. I think Build-Depends: foo
<!nocheck> should be equivalent to Test-Depends: foo, but there are probably
bears on this road that I'm not aware of yet.
RT intervention in required far too often for situations that should be handled
automatically.
I believe you include transitions here, in that case I agree. Let's try to move
that problem forward (see below). However, apart from transitions (and flaky
tests) I don't share the view that interventions are required too often (or I
would have spent time earlier to fix the biggest issues).
Like the autopkgtest scheduling being completely unaware of transition.
But that specific problem you are now working on in bug 1120799, and while this
e-mail was sitting in draft, I implemented a WIP version of a first improvement
[2]. It's a bit inspired by your suggestion. I also deployed a fix for bug
1011265 that I worked on and only had locally, which is relevant for
transitions based on Provides.
As I mentioned in reply to Adrian [0], pulling everything from unstable is the
far end of being more liberal in pulling dependencies from unstable and not
what I'm considering.
I still have to digest what you suggest, but it already took a while to realize you are regularly
talking about reverse dependencies. We need to get absolutely sharp when Depends are being
considered and when reverse dependencies (and in which flavor, source or binary). Because for
reverse dependencies it means that we're not talking about versioned Depends, but about versioned
Breaks. Unfortunately regularly only the test is broken and then a runtime Breaks might be a bit
over kill. We're missing a Breaks-Test functionality. Do you recognize that as part of
"your" problem? Currently we recommend maintainers to "just" add the versioned
Breaks *or* if they think that's overkill to just ask us. Most of the time even that goes ok in the
current machinery, as the broken package can often migrate before the breaking package, but
occasionally (like in this case), there's a deadlock.
I don't recognize Breaks as part of my problem, they are consumed by APT during
dependency resolution, nothing more.
Adding Breaks is a PITA, the extra uploads just add delays, and load to already
struggling riscv64 buildds.
And then people run out of patience and remove the autopkgtest because it
hinders testing migration more than it helps.
That might be the case, but I have the impression that's a small minority
(maybe most stay silent, if my impression is biased I wouldn't be very
surprised).
While I really want to see the autopkgtest scheduling improved I also don't
want to loose some of the feature I consider important, so it's important to
reason about which cases we're trying to fix and which price it's worth paying
to improve. E.g. like what Adrian referred to, we're catching quite some of the
missing versioned runtime dependencies, which is something I value. While
officially we don't support partial upgrades (which is also the situation
during upgrades) we've become better at it over time, also due to what
autopkgtest spots. Versioned Breaks are also valuable, but if it's only the
testsuite that's broken by an update, maybe we should have a new method to fix
that.
I'd like to distinguish the cases we've discussed so far and try to find
solution for each case, where we balance what we gain vs what we loose. I
wanted to start a list, but I also finally want to hit the send button, so that
will be for next time.
That's why I wrote down a scenario which should be a more generic solution to
both the problem I'm trying to solve with transitions for which I already
implemented a POC, and incorporate your feedback about informed guesses about
ongoing transitions and calculating involved packages.
Most what has been written in these two bugreports is too vague, code will show
what exactly is meant.
With your work in the improve-transitions branch I think I'm wasting my time
thinking about this issue and experimenting with code. So I'll go do something
else with my remaining vacation days.
Kind Regards,
Bas
--
PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
