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>
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>
When trying to break a choice, try the candidate out and see if we can
pick it without any consequences. Basically, if the candidate causes
no new conflicts or choices, we can safely pick it.
Signed-off-by: Niels Thykier <niels@thykier.net>
For some cases, like aspell-dictionary, a number of packages can
satisfy the dependency (e.g. all aspell-*). In the particular
example, most (all?) of the aspell-* look so similar to the extent
that reverse dependencies cannot tell two aspell-* packages apart (IRT
to installability and co-installability).
This patch attempts to help the installability tester by detecting
such cases and reducing the number of candidates for a given choice.
Reported-In: <20140716134823.GA11795@x230-buxy.home.ouaza.com>
Signed-off-by: Niels Thykier <niels@thykier.net>
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>
