| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This is also used as a slightly hacky way to make sure that the
apt errors go *somewhere*; eventually they should appear in the
UI somewhere.
|
|
|
|
Hopefully this will eliminate some of the random crashes
on exit that people were seeing.
|
|
This will be the foundation for the new top-level harness code.
Eventually the old code will go away, but I don't want to disrupt it
while I'm working on the new stuff.
To activate the new code, pass --new-gui on the command-line.
|
|
implementation.
The idea is to eventually transfer all the AptiutdeWindow code over
here, or possibly refactor it to be better organized.
|
|
The idea here is to (eventually) replicate the behavior of the current
TabManager, and to support a "classic" set of flat tabs, along with some
more experimental UI designs. Currently missing some (relatively) easy
features like changing tab titles, tab tooltips, etc.
|
|
There are various problems with log4cxx, especially that it seems to be
unreliable and leads to random crashes. It might be a good idea to
eventually move to a different framework or roll our own. Decreasing
the number of explicit dependencies on log4cxx is a good way to do
that.
|
|
about for a while.
As noted in the code, this is an inideal approach, but the ideal
approach isn't totally clear. The versions command still needs to be
implemented and plugged into main().
|
|
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.
|
|
Aptitude::ProblemResolver::SolutionCost.
Uncompiled since this machine lacks a working development environment.
|
|
|
|
src/generic/apt/changelog_parse.
|
|
to eliminate an error logged to _error when a temporary directory can't be deleted.
This works around the problem where sometimes the background download
queue would become unable to download anything else. That problem
seems to have been related to a message being inserted into the global
error queue. This doesn't actually fix that problem, which I suspect
is a bug in apt's Acquire, but it prevents it from cropping up in this
place.
This also reminds me: at some point the temporary file stuff should (a)
allocate a single directory in $TMP and use it for all temporary files
instead of making a zillion, and (b) get an explicit shutdown at the
end of the program that recursively deletes that directory (instead of
relying on destructors to clear it out).
|
|
|
|
This handles a lot of niceties, at least theoretically (still untested):
incremental loading, merging requests for the same screenshot (so only
one pixbuf is allocated), and caching loaded screenshots.
|
|
download queue that can accept new entries in an ongoing download and cancel arbitrary existing entries.
This is basically just a bunch of scaffolding to safely handle Acquire
structures in a background thread. Future work here could perhaps
include the ability to emit notifications about partial downloads, for
instance so that screenshots can be rendered as they're downloaded.
|
|
|
|
|
|
|
|
number of threads and parse jobs when there are lots of available upgrades.
|
|
The plan is to use BLOB storage in sqlite. This is less than entirely
efficient, but it should avoid having a lot of small files hanging
around and having to manage the cache contents myself. Hopefully the
load on the cache will be low enough that the BLOBs are reasonable.
I've split them into a separate table in the hope that it'll help.
The only thing not implemented at the moment is actually putting files
in and getting them out, i.e. the most important part. The tests are
only just started, too.
|
|
It's not as well separated as I'd like, but it's a start as far as
creating some internal structure.
|
|
This would have helped with tracking down two recent tab-close-related
bugs. In fact, I found the second one while instrumenting the code
with logging statements.
|
|
|
|
logging domain where messages about those settings are logged.
|
|
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.
|
|
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)
|
|
This is the first step towards implementing the tiering system laid out
in <20090214163554.GA8343@emurlahn.burrows.local>. "promotions" are
the evolution of "conflicts" in the current system: they store the
knowledge that "if you do this and that and that, you must push the
solution to tier N". The "promotion set" will take on the role of the
current "conflict set"; because the behavior we need is quite a bit
more complex, I've chosen to write a custom data structure rather than
leaning on the dense_setset template. That means more work (it took
me all day just to implement this initial version) and more debugging
will be needed, but on the other hand I've already stuck in some simple
optimizations that were obvious once I was working with promotion
elements and not just generic "value objects".
Unlike the existing conflict set, elements can be removed from the
promotion set. In fact, if you add a new promotion that supersedes
an existing promotion, the existing one will automatically be thrown
out. You can also remove all the promotions on one tier, or all the
promotions below tier N. The only reason for not having more general
erasure is that it's not needed, and by providing the specific cases
that I need directly, I can optimize them a little better.
The unit test verifies that a promotion set can be created and that it
sort of works, but it needs more work before I can have any real
confidence in this code. Luckily, the currect code also isn't used
anywhere. Yay!
|
|
structures.
Since global state is often implicated in various bugs, this will
probably come in handy sooner or later.
|
|
them before the cache is closed.
This eliminates the race condition / crash that was left over in the
last patch. It also annotates the background thread code in pkgview
with logging statements, which should help with future debugging.
|
|
Because "hg record" can't split diff hunks, some places that need
logging are bound up in another pending commit, unfortunately.
|
|
up-front.
Still to do:
* a working Upgrade button (right now it doesn't do the right thing).
* show the user the solution that was applied and the reasons behind it.
* let the user jump straight to resolving dependencies by hand.
|
|
the logic used by the "safe-upgrade" command-line action.
This is the first step towards the better upgrade UI (making the
safe-upgrade logic available to all interfaces); the next step is to
use the ability to reason about hypotheticals to plan an upgrade before
we change any package states. Which means I have to expose that
ability to clients of the resolver manager.
|
|
synaptic does (assume the subprocess is waiting for input if it goes 30 seconds, or whatever, without reading).
TODO: add a note in the user's manual about this.
|
|
|
|
|
|
that sets up scores and rejects).
The commit to tests/Makefile.am is needed because the tests link in the
aptitude resolver, which in turn links in the loggers.
|
|
weirdness they exhibit regarding terminal semicolons.
|
|
in aptitude.
|
