Move the logic of apply_src_policy and apply_srcarch_policy into PolicyEngine.
This fixes an issue with the excuses.yaml output introduced in commit
15e5228669: only the last verdict was added to the excuse info for that
policy.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
When a source has only arch: all binaries, the Build-Depends had no relevant
architectures, so the check was skipped. Instead check it on any architecture,
just like Build-Depends-Indep.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
The src_policy defines wether, for source items, the source policy should be
run (RUN_SRC, the default), the arch policy should be run on every arch
(RUN_ON_EVERY_ARCH_ONLY), or both (RUN_SRC_AND_EVERY_ARCH).
Signed-off-by: Ivo De Decker <ivodd@debian.org>
Regex compilation is often rather expensive and in this case, we can
do it once instad of once per migration item.
Signed-off-by: Niels Thykier <niels@thykier.net>
Note that this now also applies to binNMUs. A source block also blocks
binaries. Binaries on a specific architecture can be unblock with an
architecture-specific unblock hint.
This also means all binaries from non-primary suites
(testing-proposed-updates, etc) need approval.
Closes: #916209
Currently no policy implements this.
A policy can now implement apply_src_policy_impl or apply_srcarch_policy_impl
(or both), so apply_src_policy_impl is no longer an abstractmethod.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
apply_src_policy expects an excuse with a new source and binaries. It doesn't
apply to srcarch excuses, which only have new binaries for an existing source.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
This is a step towards making migration unit-testable. This step
reduces the need for global state (in the MigrationItem class as class
fields) and with another step we can remove the global state entirely
and enable unit tests to create migration items without having to
worry about other unit tests.
Signed-off-by: Niels Thykier <niels@thykier.net>
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>
This is useful to run tests with the data files from a specific point in time,
without changes due to ageing when the test runs later.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
When determining whether a policy applies to a given item, use the
suite class rather than the suite name.
Signed-off-by: Niels Thykier <niels@thykier.net>
This commit rewrites the make-shift "log" methods to use the logging
framework without requiring changes to the callers. This will be done
in a latter commit to keep things reviewable.
Signed-off-by: Niels Thykier <niels@thykier.net>
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>
Niels Thykier
Ivo De Decker
Paul Gevers
Paul Wise