Hi, On 12-04-2025 08:34, Marc Haber wrote:
Otoh, Essential packages can break many other packages without having an explicit reverse dependency listed since they are assumed always present and since it's a bug to explicitly list a dependency on an Essential package.
Conform 3.5: "Packages are not required to declare any dependencies they have on other packages which are marked Essential (see below), and should not do so unless they depend on a particular version of that package. [4]" That footnote was an eye-opener for me: "Essential is needed in part to avoid unresolvable dependency loops on upgrade. If packages add unnecessary dependencies on packages in this set, the chances that there will be an unresolvable dependency loop caused by forcing these Essential packages to be configured first before they need to be is greatly increased. It also increases the chances that frontends will be unable to calculate an upgrade path, even if one exists."
I am wondering whether we are migrating buggy Essential packages too quickly because we don't have a mechanism to find out whether autopkgtests are failing because of bugs in the Essential set.
Probably.
Is it maybe even a bug in Policy that packages cannot declare explicit dependencies on Essential packages because of this?
See the footnote quoted above. Without thinking long about it, I think this is a practical compromise.
Can we do something to address this situatioN?
We *could* trigger all tests for each essential package. Given how much help glibc typically already needs due to flaky tests, I don't think we should do that already. We'd also run into infrastructure limitations.
What we can already do is ask packages that depend on Essential packages, to add a hint-testsuite-triggers [1] test. That way we would at least know which packages to test for.
Paul[1] https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst?ref_type=heads
OpenPGP_signature.asc
Description: OpenPGP digital signature
