The other item includes bug numbers so this one is less useful.
Closes: https://bugs.debian.org/886509
Signed-off-by: Niels Thykier <niels@thykier.net>
The PiupartsPolicy does not use the report URL for testing, so we do
not need to store it in memory. Unfortunately, the logic was broken
and the discard did not happen.
Signed-off-by: Niels Thykier <niels@thykier.net>
If a package had:
Build-Depends: foo [i386], uninstallable-pkg
Then the excuses for amd64 would point to "foo [i386]" rather than
"uninstallable-pkg".
Signed-off-by: Niels Thykier <niels@thykier.net>
Add a new "BuildDependsPolicy" that will check the satisfiability of
the build-dependencies listed in the Build-Depends and
Build-Depends-Arch fields. This enables gating of packages based on
missing / broken build-dependencies.
There are some limitations:
* Build-Depends-Indep is ignored for now. Missing or broken packages
listed in Build-Depends-Indep will be continue to be silently
ignored.
* Being a policy check, it does not enforce "self-containedness" as
a package can still migrate before a build-dependency. However,
this can only happen if the build-dependency is ready to migrate
itself. If the build-dependency is not ready (e.g. new RC bugs),
then packages build-depending on it cannot migrate either (unless
the version in testing satisfies there requirements).
Signed-off-by: Niels Thykier <niels@thykier.net>
We basically use them as sets and do not need to rely on the ordering,
so we might as well just turn them into proper sets.
Signed-off-by: Niels Thykier <niels@thykier.net>
Rewrite _compute_scc to be iterative to avoid call recursion limit for
graphs with long dependency chains.
Signed-off-by: Niels Thykier <niels@thykier.net>
Sometimes the solver would correctly compute which items are grouped
together, but then fail to emit some groups. This is trivially
fixable by forcing an update of "before" + "after" relations.
Admittedly, this looks unnecessary, so it may just be hiding the bug.
Nonetheless, the change makes the new test_solver_simple_scc test
produce the expected result.
Signed-off-by: Niels Thykier <niels@thykier.net>
devscripts' grep-excuses expects each <li> to be on its own line. When
d7a676d0741729bb643e0b8c54b989cb747c6a4b added the verdict summary,
without an EOL, it broke grep-excuses' ability to search by maintainer.
Signed-off-by: James McCoy <jamessan@debian.org>
Signed-off-by: Niels Thykier <niels@thykier.net>
With this change, Britney can now provide a very brief summary of the
migration via one single value (YAML) or line (HTML). This solves two
issues:
* It provides an aggregated version of the policy decision without
having to loop over all policies (and even those would not give
a full verdict on their own as not all rejections come from
policies)
* It enables a simple way to inform readers of the HTML excuses of
whether a rejection is permanent or not. This should hopefully
make it easier for contributors to understand Britney and react
more pro-actively.
Signed-off-by: Niels Thykier <niels@thykier.net>
Britney has a special case for essential packages to ensure that any
package that with essential packages are not installable. This check
did not account for a case, where a package is not co-installable with
two or more pseudo-essential package part of the same OR dependency.
A contrived example based on real world data:
Package: foo
# Conflict with all providers of "awk"
Conflicts: mawk | gawk | original-awk
This alone is actually not sufficient to trigger the bug, as
_get_min_pseudo_ess_set is in theory some times smart enough to pick
an "obvious" solution between the pseudo-essential option.
When it does, one of the above ends up in the (de-facto) essential set
and then the installability tester correctly rejects "foo".
Though, even with the fix above, the handling for this is probably not
correct if the essential set is not (fully co-)installable. However,
that basically only happens if we are bootstrapping an architecture
(or testing is royally broken, in which case this is the least of our
worries).
Signed-off-by: Niels Thykier <niels@thykier.net>
