We currently have excuses.html saying:
x264 (2:0.155.2917+git0a84d98-2 to 2:0.159.2999+git296494a-2)
Migration status for x264 (2:0.155.2917+git0a84d98-2 to 2:0.159.2999+git296494a-2): BLOCKED: Cannot migrate due to another item, which is blocked (please check which dependencies are stuck)
Issues preventing migration:
Implicit dependency: x264 nageru (not considered)
Invalidated by implicit-dependency
Implicit dependency: x264 ffmpeg
Implicit dependency: x264 gst-plugins-ugly1.0
Implicit dependency: x264 handbrake
Implicit dependency: x264 libquicktime
Implicit dependency: x264 mplayer
Implicit dependency: x264 mythtv
Implicit dependency: x264 obs-studio
Implicit dependency: x264 vlc
Implicit dependency: x264 xpra
Additional info:
8 days old
Apart from `nageru` it's not clear here that some further packages need
working on to move this migration forward. In fact, the package
`gst-plugins-ugly1.0` is FTBFS
Migration status for gst-plugins-ugly1.0 (1.16.2-2build2 to
1.16.2-2build3): BLOCKED: Maybe temporary, maybe blocked but Britney
is missing information (check below)
as is xpra. The remaining packages are simply those which are part of
this SONAME transition, as such they have
Migration status for mplayer (2:1.3.0-8build6 to 2:1.3.0-8build7):
BLOCKED: Cannot migrate due to another item, which is blocked (please
check which dependencies are stuck)
All of these excuses are (or should be) "invalid", but only the ones
which are not BLOCKED_BY_ANOTHER_ITEM require direct action. We should
show this, so that maintainers can see what they need to concentrate on.
When outputting depdencency problems, consider the policy verdict of the
excuse. If it's one that indicates further work is required for that
excuse, indicate this by outputting "(not considered)".
Sometimes (for the LinuxPolicy), excuses don't have enough information
when they are processed. They need to defer some of their work until
another excuse has been evaluated and then perhaps get invalidated.
Introduce the concept of "external invalidation" to deal with this. A
policy can keep references to other excuses around, and then invalidate
them later (when processing another one). The excuse finder needs to
know this happened to remove the excuse from the list of "actionable
excuses".
For example. The Linux policy invalidates linux-foo if linux-meta-foo is
invalid. If linux-foo is encountered first, we will not yet know if
linux-meta-foo is going to be invalid. We effectively defer the
evaluation until after linux-meta-foo has been dealt with, and then we
know whether we need to invalidate linux-foo or not.
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.
All types of dependencies between excuses (Depends, Build-Depends,
Build-Depends-Indep, ...) are handled by the same code. The DependencyType is
used to distinguish between the types where needed.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
The other fields related to invalidation are currently not deterministic and
depend on the order in which the excuses are invalidated.
The new invalidated-by-other-package field is just a boolean which shows the
excuse was invalidated by some other package for some reason (without
specifying the reason). It does not depend on the order of processing and
should be deterministic.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
Admittedly, no policy adds them yet so this is currently no-op code.
However, future commits can start to rely on this infrastructure code.
Signed-off-by: Niels Thykier <niels@thykier.net>
Cherry-Pick: 80bf9060de
Cherry-Pick: f32907acea
Cherry-Pick: 9ef496177f86b18d9f910da1360dd773b82f1fb7
Cherry-Pick: b16530a37d
Signed-off-by: Niels Thykier <niels@thykier.net>
Flatten the defaultdict(set) for unsat_deps into a standard dict for output
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>
devscripts' grep-excuses expects each <li> to be on its own line. When
d7a676d074 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>