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" 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>
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>
