Hi Bas, 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. 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?
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?
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.
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.
Paul[1] https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst
[2] https://salsa.debian.org/elbrus/britney2/-/commits/improve-transitions
OpenPGP_signature.asc
Description: OpenPGP digital signature
