Technically, we simply sort by the "hint-size", but it for most parts
have the effect of putting single item earlier. Note this is /not/ a
perfect solution, but it is a simple heuristic exploiting the common
case.
Signed-off-by: Niels Thykier <niels@thykier.net>
This made iter_packages_hint a thin wrapper around try_migration, so
it was inlined into its only caller "do_all".
Signed-off-by: Niels Thykier <niels@thykier.net>
The callers of get_dependency_solvers need to do those table lookups
anyway. By moving it out, it is now possible to reuse the results.
Signed-off-by: Niels Thykier <niels@thykier.net>
Rely on the Installability tester to locate all of the affected
packages plus their transitive reverse dependencies. As the
InstallabilityTester is suite agnostic, the set of affected packages
now includes (versions of) packages not in testing, which is filtered
out during the check.
Signed-off-by: Niels Thykier <niels@thykier.net>
If we have an up-to-date arch all package available for this architecture,
that doesn't mean this architecture has an up-to-date build. We need an
architecture specific up-to-date package for that.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
For fucked architectures, binaries from older versions are allowed to be in
testing, so we only remove them if they are gone from unstable.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
Old binaries in testing are usually old versions of libraries that where
smooth-updated. These should only be kept in testing as long as they are
needed to install other packages in testing. When they are no longer needed,
they can be removed, even if the old library is still in unstable (where it
might be needed for reverse dependencies which are not in testing).
Signed-off-by: Ivo De Decker <ivodd@debian.org>
Move nuninst cloning out of the check loop and always populate the new
nuninst entirely.
This will allow some simplifications in other places.
Signed-off-by: Niels Thykier <niels@thykier.net>
Use a set to filter out seen items to avoid doing O(n^2)
de-duplication. For very large hints, this can take considerable
time.
Using "seen_items" to build the actual hints on the (unverified)
assumption that Python can do something "smart" to turn a set into a
frozenset faster than it can with a list.
Signed-off-by: Niels Thykier <niels@thykier.net>
Britney is now smart enough to produce the same result from hints
regardless of the order of the items in the hint. With this in mind,
we can have the original auto-hinter produce hints as sets and filter
out duplicates as we produce them.
Note that the hints are sorted to produce deterministic output (to
make it easier to compare the hints between runs and changes).
Signed-off-by: Niels Thykier <niels@thykier.net>
Avoid some cases of O(n^2) behaviour in sort_actions and reduce the
size of n for the remaining O(n^2)-ish behaviour by filtering out
removals early on.
Signed-off-by: Niels Thykier <niels@thykier.net>
It's more natural to say "check this package if the current arch is in
this list" than "do not check this package if the current arch is not
in this list"
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
This updates the doop_source and _compute_groups functions so
that binary packages that are built from a different source
aren't included as part of an update to the original source.
In the event that it's a binary-only update, also don't remove
the hijacked packages from testing.
This change also removes an obsolete comment regardarding pre-conditions
for the _compute_groups function.
The live-data tests rely on an inconsistency, since they were before
Britney started to record the Essential field.
Signed-off-by: Niels Thykier <niels@thykier.net>
britney assumes that a package build is uniquely described by its
name, version and architecture. Particularly when constructing
Packages files by hand for testing purposes this assumption can be
violated, leading to confusing behaviour. This change makes britney
look for such mismatches, and report if any are found.
In some scenarios, it was possible to trigger a bug in the
installability tester, where it would fail to update the "choices" set.
The requirements for triggering this seems to be something like:
* Obtain a choice that is possible to solve.
* Resolve the choice without recursing (with a backtrack point)
* Obtain a second choice that is impossible to solve.
After the two first steps, the installability tester would fail to
update the "choices" set (or, rather, changes would be invisible to
the "_pick_choice" function). Fortunately, most packages are either
trivially installable or trivially uninstallable, so the bug seems to
be rather rare if triggred at all.
Signed-off-by: Niels Thykier <niels@thykier.net>
Niels Thykier
Ivo De Decker
Cyril Brulebois
Adam D. Barratt
Anthony Towns