| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
behavior, and fix setting safety levels using the old names.
aptitude's behavior should now be fully compatible with pre-0.6.2
releases (by default). The safety level change fixes the fact that
you could raise safety levels using the old names but not lower them.
|
|
The only remaining references to tiers are in backwards-compatibility
code; the "safety" cost component is composed of several "tiers" whose
values can be configured.
|
|
that it takes a break-soft-dep tier operation.
|
|
That this didn't cause a unit test failure indicates a hole in the unit
tests...which I don't have time to plug right now.
|
|
Still needed: a parser, unit tests, documentation, and the final
tying-together code in resolver_manager.
|
|
This also starts to introduce the concept of a "cost component": an
intermediate counter of some sort that can be used to assemble a cost.
The eventual goal is to haved named components, like "removals" and
"upgrade-cancels", and operators that combine them to form new cost
components, like "removals + upgrade-cancels".
"cost component" / "cost" is the terminology I eventually want to move
towards, in favor of the confusing and badly-chosen "tier level" and
"tier". This commit starts to introduce that terminology, and all my
new commits will use it (except where local consistency demands
otherwise). Eventually I need to make a pass over the code and rename
lots of stuff.
|
|
this is the first step towards being able to minimize the number of changes meeting a criterion.
The biggest change for this is that the new cost objects (tier operations)
are not totally ordered, so various places that used to take a maximum
now take a least-upper-bound instead; similarly for minimum and
greatest-lower-bound. Still to do: find a sound way to allow the resolver
to add together costs instead of upper-bounding them: "this change
will force us to remove 10 packages".
The new code seems to be a little too slow -- probably it lost some
optimizations by accident. It does seem to be correct, though.
|
|
This moves all those routines into aptitude_universe, because the code
that will want to use them doesn't touch the resolver directly (only
its output). Also implemented an (untested) routine to translate
tiers into names in a configurable manner, and created a new logging
domain for setting up initial tiers.
|
|
|
|
The syntax is "increase-tier-to TIER PACKAGE [VERSION]". The tier is
either an integer, "conflict", or "minimum" (although "minimum" has no
effect, so there's no point in using it).
|
|
Right now the default tiers are:
10,000 -> "safe" solutions containing only new installs, upgrades
and "keeps".
20,000 -> solutions that cancel all the user's actions.
30,000 -> solutions that remove packages.
40,000 -> solutions that break holds.
50,000 -> solutions that install non-default versions of packages.
(the subordinate tier is the version priority)
60,000 -> solutions that remove Essential packages.
Still to do: add tier hints, add a way to set tier names, show tiers
and/or names in the UI (in place of the meaningless and confusing
score value).
|
|
plain integers.
This allows us to classify solutions in a more fine-grained way. In
particular, it provides a not-horrible way to integrate apt pin
priorities into the resolver's decisions, by making them a subordinate
level of ranking to the main tiering system.
The current plan is that the first level of tiering is the only one the
user sees (by default) and the only one that can be directly configured.
The subordinate levels are filled in automatically (pin priorities are
all I have in mind now, but I don't discount the possibility of
introducing more levels in the future).
|
|
choice_sets, rather than manually storing the different types of choices in the solution object.
This has two beneficial effects. First, it should make it a bit easier
to add a new choice type, although many parts of the program will still
have to be touched. Perhaps more importantly, this provides a cleaner
conceptual model of what the resolver does: it finds "choice points"
(that is to say, dependencies that need to be solved) and makes choices
at them.
This commit sneaks in a few optimizations that I came across in the
process of rewiring all the resolver logic. The big one is that testing
whether a solution violates a user constraint now requires steps
proportional to the size of the solution, not to the number of user
constraints. (each step is logarithmic in the number of constraints,
but that's still a big improvement)
|
|
initial states.
This can be used, for instance, to compute an upgrade without
flagging the upgrade first.
|
|
everything else (oops).
|
|
hypothetical installations.
|
|
The old name was annoyingly long and also redundant.
|
|
dependency resolutions that apt would have.
This needs some testing, as soon as I can figure out a good test case.
The basic mechanism is to use the joint scores that have been in there
for a while: if a dependency's targets aren't currently installed, we
either apply a joint score to installing the depending package and the
first dependency (the one apt would pick), OR (if the depending package
is installed) we apply a score to the first dependency only.
Note that this happens even for non-OR, non-virtual dependencies. Not
sure if this is a good idea, or how to easily prevent it.
|
|
missing version, not select_all.
|
|
mandate versions.
|
|
add_action_scores() instead of the resolver's constructor, and use them to configure the resolver.
Still TODO: the code to account for actions performed on the resolver
won't know about the hints and they won't be logged or printed with
the debug output. Also, they need to be documented.
|
|
|
|
the given version.
|
|
|
|
It makes more sense to me to put the operation first (as in, e.g., ">5.0").
|
|
|
|
installing the package.
This will be used, e.g., to describe a hint that says to reject a package entirely.
|
|
|
|
This commit also introduces the ability to select ranges of versions,
not just individual versions, and the ability to compare two hints.
All untested.
|
|
This loses a little functionality in some places. Searches that go
item-by-item (e.g., curses "/") are broken for ?term matchers (and
hence also bare strings), and searches that return string groups
(e.g., "aptitude search" with a format pattern containing substring
IDs, or the "pattern" grouping policy) don't work. But other than
that, everything should work.
|
|
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.
|
|
|
|
|
|
packages and installing their full replacements instead.
Unfortunately, I can't test this: I don't have a handy example of a
package that conflicts/replaces/provides another package (in the
current archive there are no pairs where the replaced package is a
real package, which makes sense).
If nothing else, I can manufacture an example, maybe tomorrow though.
|
|
|
|
actions that break package holds.
The user can override these rejects individually in the usual manner,
or globally via Aptitude::ProblemResolver::Allow-Break-Holds. This
should make the resolver's behavior a lot more intuitive for users,
but it doesn't erase all the bugs on this subject due to the fact that
apt's auto-install logic will break holds.
This is one of many places (e.g., conflicts handling, reliable choices in
safe-upgrade) where I think that apt's auto-install handling is dragging
aptitude down. It may be time to replace it for good.
|
|
indicator will now say that it cancels everything instead of listing the component keeps that make it up.
|
|
|
