[Aptitude-devel] Acquire considered non-threadsafe
dburrows at debian.org
Tue Dec 1 00:09:23 UTC 2009
On Tue, Nov 24, 2009 at 12:00:21AM +0100, Julian Andres Klode <jak at debian.org> was heard to say:
> On Mon, Nov 23, 2009 at 07:41:42AM -0800, Daniel Burrows wrote:
> > Hm. I'm pretty skeptical about writing a system tool like this in a
> > high-level language. Both from the point of view of dependency
> > fragility and because you want it to be easy to access the functionality
> > from other languages. In fact, I've occasionally wondered if it makes
> > sense for the public API of an apt successor to be pure C (even if the
> > implementation is C++ behind the scenes). C++ ABIs are obnoxiously
> > fragile and poorly defined, for one thing. (although very convenient if
> > you're writing in C++)
> Vala compiles to C, and provides a C-API comparable to other GObject libraries
> such as GTK+. You get a C library with a header file and everything, and you
> can write applications using the library in C. For now, dependencies are
> libgee1 (container classes)
> libsoup2.4-1 (HTTP/HTTPS acquire part)
> The latter one could be replaced with a limited http downloader for embedded
> systems; which only depends on libglib2.0-0.
Ah, I didn't get that from a quick Google search. That makes more
> > > Some kind of a roadmap:
> > >
> > > * identify stuff we don't use anymore and remove it, eg.
> > > apt-pkg/vendor*, apt-inst/database*, apt-inst/deb/dpkgdb*.
> > > * drop compatibility for GCC < 4.3, and other stuff older
> > > then what is included in Debian Lenny.
> > > * rework the buildsystem using CMake
> > (ABI breaking stuff)
> > * Write a more organized download system. (see below)
> > Maybe also figure out a style guide for C++ going forwards (e.g.,
> > recommend not using exceptions, using smart pointers, using STL
> > containers, etc).
> Or copy Google's style guide and remove the stuff we don't like; and
> adjust it to our coding standards. Their style guide is very complete,
> and thus a good base.
> > In aptitude, I have built an internal API that provides a low-level
> > URI downloader running in a background thread. Currently it's based on
> > Acquire, but with a little work it could replace Acquire instead
> > (at first glance, the Acquire main loop and the download queue management
> > would need to be incorporated). I think it's a good example of the
> > simple interface I'm thinking about, anyway:
> > http://hg.debian.org/hg/aptitude/head/file/b8a7fc61b13c/src/generic/apt/download_queue.h
> I'm missing a few parts like a target filename, but maybe this is defined
> somewhere else?
There are a few things that would need to be added. In
aptitude, the target filename is generated as a temporary name and
passed out as a return value via the completion callback. A generic
version of this would probably specify the file as a parameter to
queue_download(). The status callbacks are also incomplete -- it needs
at least a way to provide some sort of message string giving the current
More information about the Aptitude-devel