Re: DoListUpdate == ?
On Fri, Jan 11, 2008 at 09:54:32AM +0100, Michael Vogt <mvo@debian.org> was heard to say:
> On Thu, Jan 10, 2008 at 06:43:00AM -0800, Daniel Burrows wrote:
> > I noticed in the latest apt changelog that there's a reference to a
> > "DoListUpdate" branch that has something to do with frontends and
> > running list updates. I can't find any documentation of what this is
> > or what its implications are, though. Could someone enlighten me?
>
> My bad, sorry. I wanted to send you a patch directly, but didn't
> manage to. The problem is that there is no common way to do a simple
> apt-get update list operation in the frontend. So there is some
> duplication of code and no central place to get e.g. hook scripts
> working (a whishlist item for some time now).
>
> The solution was to add a
> bool ListUpdate(pkgAcquireStatus &progress, pkgSourceList &List, int PulseInterval=0)
> method into algorithms. It will load the indexes into the fetcher, run
> it (with the given pulse interval) and report problems via the _errror
> interface. It will also deal with list cleanup and now is cappable of
> running APT::Update::Pre-Invoke and (if everything was successful
> (Post-Invoke) hook scripts. This is useful for systems like debtags
> that will have to update there database after a apt-get update.
>
> I ported python-apt and synaptic to the new interface (in bzr)
> already. I looked briefly into aptitude as well, but it seems more
> tricky as it splits the operation more into various threads.
>
> I hope this helps, I'm happy to change anything so that it suits
> aptitude better (if needed).
aptitude has had a wrapper routine for updating package lists for a
while. However, unlike ListUpdate, aptitude unifies all its tasks behind
a single interface (download_manager) with well-defined rules about what
gets called in which thread. This means that all the special logic to
orchestrate the apt end of a download can go in one place, all the code
for the frontends (aptitude has two, command-line and curses) can go in
another place, and they can communicate at arms-length through signals
and virtual methods.
The interface points I found useful in aptitude are:
(1) a "prepare" function call that sets up the download (i.e.,
loads up the fetcher) and signals failure if the download can't
be set up.
(2) a "do_download" function call that runs the actual download
and is safe to call from a background thread (i.e., other
threads may be running, examining the cache, etc while the
downloader is running). This is approximately equivalent to
pkgAcquire::Run (in fact, it looks like the only implementation
in aptitude just passes through to Run).
(3) a "finish" function call that performs any post-run operations.
It's passed the result of calling do_download and runs in the
main thread.
Essentially, this separates the "download setup" and "post-download"
code into separate routines that can be invoked at points that are
appropriate for the architecture of the driving code. Each downloader
in aptitude is just a class that can be handed to the downloading
machinery of the current frontend: "do this and show the user what
you're doing".
So the shortest route to making this useful for aptitude is to just
provide routines preListUpdate to set up and update and postListUpdate
to complete it.
OTOH, I think that the idea of having an interface for download tasks
with pre/download/post methods might be worthwhile to include in apt
itself. There are a few subtleties that would have to be dealt with;
for instance, the "download and install" class in aptitude exports some
sigc++ hooks that are called just before and after running dpkg. In
an apt implementation these would presumably be replaced by virtual
methods (aptitude could hook into the virtual methods and call signals).
aptitude uses these to suspend and restart curses; other frontends might
need something similar to (for instance) pop up a terminal.
Daniel
Reply to: