Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
Now that the resolver continuations run in the foreground thread, this
was causing irreconcilable deadlocks (since the foreground thread would
be waiting for someone to post the return result, which could only
happen when the foreground thread finished running the continuation and
polled for new posted thunks).
|
|
|
|
|
|
|
|
|
|
|
|
around the command that's run).
|
|
Thanks to Matt Kraai for the initial version of the text.
|
|
archive names.
|
|
|
|
Better to get this out sooner than later.
|
|
|
|
|
|
equivalents. (Closes: #540230)
apt's version of MarkFollowsRecommends() reads the two options
Apt::AutoRemove::RecommendsImportant and ...::SuggestsImportant,
where aptitude historically used Aptitude::Keep-Recommends and
Aptitude::Keep-Suggests. This means that there were two sets of
options controlling aptitude's behavior, one of them undocumented.
This change mostly just alters the documentation to make the apt
versions the "official" place to set the behavior -- and also to
document their existence.
One thing to note is that Apt::AutoRemove::RecommendsImportant
defaults to "true", whereas Aptitude::Keep-Recommends defaulted to
"false". This is not, however, a change in behavior; instead, it
just brings the documentation in line with how the program already
behaves.
|
|
|
|
(Closes: #492832)
|
|
This was the #1 complaint from users regarding the 0.6 code. Xapian
support is still there (via the ?term matcher), but it's not the
default. We might want to make this an option again in the future; I'm
not sure.
|
|
conflicts instead.
Triggered by the observation that aptitude was removing grub without
any user interaction, which I believe is caused by the greedy resolver.
|
|
The differences between the two codepaths have been steadily decreasing;
I wanted to add support for "aptitude safe-upgrade foo" as "upgrade only
foo", and this was the easiest way of doing so. It also means that
safe-upgrade supports all the postfix commands that the other package
actions do.
There is an asymmetry between safe- and full-upgrade, in that
safe-upgrade, if given parameters, will ignore all packages except the
ones listed, whereas full-upgrade will always upgrade everything in
addition to performing the listed actions. If I could go back in time
both would behave the way safe-upgrade does now; I think its behavior is
more useful, and unless there's a huge amount of confusion caused by
this discrepancy, I plan to leave things the way they are.
|
|
|
|
|
|
and enable the new logging by default with --log-resolver.
Currently, the only INFO level message is the existing promotion that
a new promotion was redundant with.
|
|
|
|
|
|
Wooooops.
|
|
|
|
inkscape > file > document properties > crop page to selection
|
|
|
|
|
|
|
|
irrelevant technical details, etc.
I hope it's better now, anyway.
|
|
We could stand to have a little more documentation here, maybe with
some examples?
|
|
|
|
|
|
|
|
|
|
parsable resolver logs suitable for use with, e.g., the resolver-visualize tool.
|
|
(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.
|
|
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.
|
|
The documentation needs work, especially the config file reference
entries -- really, logging should be its own section (maybe an
appendix?) with a list of all the logging categories.
|
|
|
|
understand what it does.
|
|
|
|
unadorned strings are now ?term, not ?name.
|
|
exactly.
Among other things, this will allow a non-hacky and reasonably
efficient fix for how packages are matched by resolver hints.
|
|
Previously we sometimes Capitalized All Words and sometimes only
Capitalized the first word. Now we always capitalize just the first
word.
This commit also expands UI to "user interface" in one section title.
|