As part of a migration, we remove all the existing binaries built by
the source (possibly on a particular architecture) from testing; this
includes architecture-independent binary packages. However, when a
binNMU is in *pu, only the arch-dependent binary pakcages are present.
As a result, after the migration the architecture-independent packages
are no longer present in testing. This usually isn't a practical
problem, as dak will re-add them when it generates the packages files.
It is, however, wrong and will break if a source migration is tempted
during the same run as (and after) the *pu binary migration happened.
The simple fix is to not remove the architecture-independent packages
when performing such migrations.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
In the rare case that a hint removed an uninstallable binary, the
binary could still be included in the nuninst counter.
Regression introduced in a46dd88.
Signed-off-by: Niels Thykier <niels@thykier.net>
sort_actions() can be quite expensive and it is wasteful to resort
actions after each successful "easy"-hint.
Signed-off-by: Niels Thykier <niels@thykier.net>
There are no uses of "lundo" left for a non-hint recurse run (i.e.
the "main run"), so there is no point in building it.
The "lundo"-list is still used in the recurse run of a "hint"-hint.
Signed-off-by: Niels Thykier <niels@thykier.net>
The "do_all"-method now checks the architectures of all changes
applied. If they entirely consist of items from "break archs", then
"do_all" will disregard the current "break archs" setting when
comparing nuninst counters.
This change avoids unintended installability regressions on break
arches when a hint (manual or automatic) apply only to packages on
break arches.
Signed-off-by: Niels Thykier <niels@thykier.net>
Rename local variables and avoid repeated chained lookups. In
particular, avoid confusing cases like:
[...]
version = binaries[parch][0][binary][VERSION]
[...]
binaries[parch][0][binary] = self.binaries[item.suite][parch][0][binary]
version = binaries[parch][0][binary][VERSION]
Where "version" here will refer to two different versions. The former
the version from testing of a hijacked binary and the latter the
version from the source suite (despite the look up using the "testing"
table, due to the testing copy being updated).
Notable renamings:
* binaries => packages_t (a.k.a. self.binaries['testing'])
* binaries[parch][0] => binaries_t_a
* binaries[parch][1] => provides_t_a
* Similar naming used for "item.suite" instead of "testing"
The naming is based on the following logic:
* self.binaries from "packages" files
(by this logic, it ought to be "self.packages", but that is
for later)
* The "_X_a" is short for "[<suite>][<parch>]" look ups.
* binaries_X_a and provides_X_a are the specialised parts of
packages_X_a that deal with (real) binary packages and
provides (i.e. virtual packages) respectively.
Signed-off-by: Niels Thykier <niels@thykier.net>
Extract a specialised iter_packages_hint from iter_packages that only
deals with applying hints. This simplifies iter_packages AND avoids
having to re-compute the uninstallability counters after each single
item in the hint.
This means that a hint can now avoid triggering expontential runtime
provided only that the "post-hint" stage does not trigger expontential
runtime. Previously the hint had to be ordered such that none of the
items in the hint caused such behaviour (if at all possible).
Signed-off-by: Niels Thykier <niels@thykier.net>
Avoid creating two dependency clauses for dependencies emulating a
"version range" a la:
Depends: pkg-a (>= 2), pkg-a (<< 3~)
Previously this would create two clauses a la:
- (pkg-a, 2, arch), (pkg-a, 3, arch)
- (pkg-a, 1, arch), (pkg-a, 2, arch)
However, it is plain to see that only (pkg-a, 2, arch) is a valid
solution and the other options are just noise. This patch makes
Britney merge these two claues into a single clause containing exactly
(pkg-a, 2, arch).
Signed-off-by: Niels Thykier <niels@thykier.net>
The "new" auto hinter relies on partial ordering to determine, when
what can migrate (and what needs to migrate at the same time). At the
same time, it leverages on "_compute_groups" to allow it to include
"removals" in its hints.
Signed-off-by: Niels Thykier <niels@thykier.net>
Avoid smooth-updating libraries in hints, when all of their reverse
dependencies will certainly disappear in the same hint.
Note that in "hint"-hint, reverse dependencies removed in the
following "full run" will not cause the smooth-updated library to be
removed. Instead these will still be removed in the end as usual, but
in some cases that is too late.
Signed-off-by: Niels Thykier <niels@thykier.net>
Rename find_upgraded_binaries into _compute_groups. The new method
will also compute what binaries will be updated in or added to testing
after migration.
Signed-off-by: Niels Thykier <niels@thykier.net>
Based on Colin Watson's code to do the same from the "britney2-ubuntu"
repository[1] revision 306, 308 and 309.
Notable differences include:
* output include version of source package being removed
* output prefix removals with a "-" (otherwise it would be identical to
a upgrade/new source with the change above).
[1] http://bazaar.launchpad.net/~ubuntu-release/britney/britney2-ubuntu/revision/306
Signed-off-by: Niels Thykier <niels@thykier.net>
This introduces a new variable HINTSDIR, which overrides the location of the
Hints dir (normally it is read from the UNSTABLE dir).
Please note that this is the location of the dir that contains the Hints dir.
Signed-off-by: Niels Thykier <niels@thykier.net>
This introduces a new variable OUTPUTDIR, which overrides the location where
the new dates file is written. This allow to run britney against a read-only
copy of the data.
Signed-off-by: Niels Thykier <niels@thykier.net>
Set the default to maxint until we've read something.
Reported-by: Ivo De Decker <ivo.dedecker@ugent.be>
Signed-off-by: Julien Cristau <jcristau@debian.org>
The new Installability Tester (IT) module replaces the remaining
C-parts. Unlike C-implementation, it does not give up and emit an
"AIEEE" half-way through.
In order to determine installability, it uses two sets "musts" and
"never". As the names suggest, the sets represents the packages that
must be (co-)installable with the package being tested and those that
can never be co-installable. For a package to be installable, "musts"
and "never" have remain disjoint.
These sets are also used to reduce the number of alternatives that are
available to satisfy a given dependency. When these sets are unable
to remove the choice completely, the new IT defers the choice to later.
This occasionally reduces backtracking as a later package may conflict
or unconditionally depend on one of the remaining alternatives.
Signed-off-by: Niels Thykier <niels@thykier.net>
We stopped populating the element with real data some time ago, it's
time to drop it entirely.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Multiarch adds a Depends: foo:any syntax, permitted only if the
target of the dependency is "Multi-Arch: allowed". This has
been supported by dpkg and apt for some time and is now safe to
use in unstable.
[Adam D. Barratt: adjusted to use consts.py]
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Adam D. Barratt
Niels Thykier
Ivo De Decker
Julien Cristau
Colin Watson