We only want to add packages which conflict in testing, but don't
conflict in unstable. For those, the newer version (from unstable)
probably fixes the conflict.
When an arch:all binary is uninstallable on a non-nobreakall arch, don't
block it, but still mark it as uninstallable, so the autopkgtest policy
knows not to schedule tests for it.
Currently when a package is uninstallable on an arch, no autopkgtests for that arch are triggered
and the autopkgtest policy blocks migration. However it's not the job of the autopkgtest policy
to judge uninstallability and packages that build an arch:all package that just isn't installable
on the autopkgtest arch should not be blocked for this.
Closes: #918620
Use the info based on the binaries in the Suite object, instead of the
inst_tester. This should also include packages that are in testing, but
are not installable.
Rework the dependencies between excuses.
Dependencies are specified based on packages (source or binary). Based
on these packages, dependencies on other excuses (that have these
packages) are calculated.
As with package dependencies, dependencies between excuses can contain
alternatives.
Each alternative can satisfy the dependency, so the excuse only becomes
invalid if all of the alternatives of a specific dependency are
invalidated.
Tracking of the alternatives and their validity is moved to separate
objects.
Adding a source parameter to the SourcePackage allow finding the source
the object is referring to, so that parameter doesn't have to be passed
along separately.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
Because autopkgtest failure in a package is now a serious bug (RC), packages
that don't opt-in should not be tested. Due to the way autopkgtest and autodep8
work together, package that don't declare they have an autopkgtest can still be
tested. However, maintainers should not be force to say their package doesn't
work with autodep8 by introducing a fake test.
When there is no test in testing, and a failing test in unstable, don't
allow the package to migrate. Doing so would make it instantly RC-buggy.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
If a new pseudo-essential package was added to testing *and* it is
mutually-exclusive with an existing member, britney would incorrectly
flag it as uninstallable (unless another change triggered a cache
invalidation of the pseudo-essential set).
With this commit, the cache invalidation is now done based on whether
we add something that *might* be in the (effective) pseudo-essential
set. It is an overapproximation as there are cases where the
invalidation is unnecessary, but at the moment it is not a performance
concern.
Closes: https://bugs.debian.org/944190
Signed-off-by: Niels Thykier <niels@thykier.net>
The optimizations relies on assumptions that are not valid with the
allow-uninst that has not been corrected. When these assumptions, we
end up with invalid nuninst counters.
Signed-off-by: Niels Thykier <niels@thykier.net>
Ivo De Decker
Paul Gevers
Niels Thykier