| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
user constraints any more, as it is no longer necessary to do so.
This was added years ago as a hack, to prevent the resolver from
thrashing around when there was a user-constrained version somewhere
on its search path. This was necessary only because the resolver
couldn't generate higher-order information about deferred solutions.
Since it now can, that code is totally unnecessary: it causes the
search to examine many more nodes than it would otherwise have to,
rather than using the pretty good heuristic of "take the dependency
with the lowest branching factor".
|
|
This commit introduces solution tiers, replacing the old conflict,
deferred solution, and already-generated-solution structures with
a system based on promotion tiers. Currently this isn't used to
actually order resolver results; however, it is used to accumulate
higher-order information about deferals that couldn't be calculated
before, and to accumulate some information about soft dependency
breaks. (currently they are still somewhat restricted, though)
The next step is to push the use of the new choice structure outward,
and maybe to profile the new code: it achieved a four-fold reduction
in the number of search nodes visited in a moderately large upgrade
test, but doesn't perform any faster in real time. I'm guessing
there are some inefficiencies there that I need to look at.
|
|
This is needed so that the resolver manager can determine whether to
create a resolver when the initial state has been modified.
|
|
while we're finding out which broken dependencies exist.
Instead we now just create one empty solution and re-use it.
|
|
Not tested as well as it should be.
|
|
|
|
(Closes: #482825)
Hopefully this won't be too bad for performance, because it only
searches 50 nodes past the first one. The one thing that worries me is
that it does this search *every time* that the resolver runs, even if
it's just going to return an enqueued solution from the last run ...
but still, it should be fine unless you're generating hundreds of
solutions (in which case we have an EPIC RESOLVER FAIL).
I think this breaks rejects/accepts. More work needed there.
|
|
not crash.
Simpler: it now takes the number of packages, not the whole universe,
as its initialization parameter.
Not crashing: the resolver was passing a pointer to a
not-yet-initialized universe into the constructor; now it uses the
universe that was passed as a parameter instead.
|
|
each dependency found by dep_iterator().
This is necessary when we have overridden the initial state, since the
universe doesn't know about initial states. Anyway, the broken dep
iterator already calls broken_under() over and over to sanity-check the
broken dep list, so that's already the canonical source of information
about what's broken.
|
|
|
|
universe's current state.
Third time should be the charm: my first two attempts at implementing
this (by putting it into the universe, or directly into the resolver
and not the solutions) went nowhere. The current approach treats the
initial state as a property of the resolver, but also as a property of
the solution object. This is needed mostly because solutions have to
be able to tell what version of a package is installed after applying
them, but it makes some sense.
There are some leftover bits of cruft that I need to excise in the next
patch (they're from intermediate versions of the code) but I wanted to
commit this now that it's compiling and not obviously breaking anything.
Still to do:
* The initial state is passed around in many ways when creating
solution successors; I should look at whether weights really
need to store an initial state, and whether we need to pass an
initial state in as a parameter. (similarly, if weights do need
an initial state, should we also pass one as an argument to root_node?).
* We need test cases for this new code.
* If solution_weights continues to store an initial state, maybe it
should be renamed to something more accurate.
* Need to ensure that aptitude_resolver.cc stops using p.current_version()
in favor of get_initial_state().version_of(p).
* Need to check that aptitude_resolver_universe doesn't depend on the
initial version being the InstVer in unexpected ways. e.g., look at
the broken dep iterator.
|
|
in the problem resolver logging.
|
|
|
|
|
|
by hand.
Calling set_debug(true) will set up the logger to mimic the past
behavior, but once I get hooks in to configure logging, it will
be possible to send output to a log file, to enable some messages and
not others, etc.
It might be good to have more logging domains than just the one,
but I'm not sure how to split the log messages up right now.
|
|
I never found a good use for this option, its most likely effect is to
lead to exponential blowup, and it makes it hard to efficiently
implement the behavior of picking the broken dependency with the fewest
number of successors.
|
|
creates the least number of successors.
Since which dependency we pick is arbitrary, it makes sense to pick the
one that makes the tree less branchy. As before, we always prefer
dependencies that impinge on user constraints, in order to get those
out of the way up-front.
This makes the max_successors option meaningless; it should be purged
from the configuration and from the documentation.
|
|
|
|
Recommendations.
The problem here was that aptitude didn't consider allowing a recommendation to
stay broken to violate a requirement that a resolving version of the package should
be chosen. The result was that the safe resolver kept asking for more versions,
thinking that it was monotonically approaching the solution, but it was actually
just building a power-set of possibilities wrt which recommendations were to be
installed.
|
|
"fix" recommendations.
Empirically speaking, this is generally not useful, so don't generate
it as a possible solution. This is done simply by not considering
other versions of the source package of soft deps; the UI that lists
solutions to a given dependency also had to be tweaked to know about
soft deps (ew, this knowledge should be in the resolver).
|
|
of actions are all performed.
Hopefully this will provide a reasonable basis for handling
conflicts/provides/replaces relationships: the idea is basically
to add a bonus to "remove this pacakge and install its replacement",
so the resolver can climb over this hill.
The next step is to detect c/p/r relationships and actually add
these scores to the resolver.
|
|
|
|
involved in broken deps for any enqueued solution.
This is necessary since the number of broken deps affects
the order in which solutions are processed.
|
|
solution information.
Actually this is an upper-bound on the number of steps we ran for; the
main goal is to allow us to reproduce the same solution later by using
the same tick count, so some built-in leeway is a good idea (it might
even be good to increase the tick count by a factor of 2 when writing
the test file later).
|
|
accumulates a trace of the packages related to a given package.
This is all the packages that were ever examined as the source or target of a dependency.
TODO: I'd like to be able to write this set with packages that don't appear in
the set pruned from dependencies. Can this be done?
|
|
|
|
This tree version is still BROKEN. This commit changes a bunch of code mechanically,
and completely fixes all the subdirectories and files through download_screen in
the top-level directory.
Some unfortunate namespace choices in cwidget showed up here. widgets and config
should probably be merged into the cwidget namespace, and I've created namespace
aliases that pretend this happened as I go through the .cc files. Luckily, that
change can largely be accounted for automatically.
|
|
|
|
Previously, the program would unceremoniously abort when the resolver
tossed an exception; now exceptions are caught, propagated to the main
loop, and reported to the user. It's even possible to keep searching
for more solutions, although some solutions (the ones on the branch
that blew up) are probably toast.
|
|
(e.g., what the solution under consideration is and which dependency wasn't broken) when an assertion fails. Hopefully means I get more useful info in bug reports!]
|
|
about the dependency for which we removed a source. Without this change we would generate more solutions containing a solution that involved removing dependency sources (possibly).]
|
|
always checking all outstanding dependencies for immediate solvability, so later conflicts are not hidden by earlier ones.]
|
|
|
|
non-broken dependency is encountered.]
|
|
|
|
|
|
tracking knows about them.]
|
|
abstract package system interface in the doxygen comments, and correct the class documentation of the generic problem resolver.]
|
|
|
|
null solution.]
|
|
|
