[Aptitude-devel] Acquire considered non-threadsafe

[Daniel Burrows]

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
> 	libglib2.0-0
> 	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
sense.

> > > 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.

  Sure.

> >   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
status.

  Daniel