[packagekit] Maintainer wanted for PackageKit Apt backend

[Tom Parker]

CC'ing to the PackageKit list, because I'm starting to think I need to
send this one to them as well.

On 23/10/2007, Jonathan Riddell <jriddell at ubuntu.com> wrote:
> Hi, I'm looking into the possibility of using PackageKit in Kubuntu.
> Could you tell me what your plans are for the apt backend?  Do you
> expect it to be complete any time soon?

Short version: dunno.
Long version: I'm currently in a situation where I don't have a lot of
time to work on the apt backend, as I've got a massive stack of other
things I need to do (process comments for PhD thesis, do stuff for
umpteen papers that I need to work on, etc) and I can't really
continue to commit time to PackageKit as the primary maintainer of a
backend at this point.

I can find time to comment on mailing list stuff and *occasionally*
spend some time on working on bits and pieces, but given the rapid
pace of PackageKit development at this point, and the level of work
that needs to be done on the apt backend just to get it up to speed
with the *current* level of stuff required is beyond my capabilities
to provide in the limited free time I've got right now.

In other words, if someone else wants the job, I'm very willing to
hand over the apt backend to someone else....

Things that the new maintainer would need to work in are in two
groups: firstly, the core "how do we provide a fast interface to apt"
problem, and secondly, the grunt work working through the long list of
the missing API that the apt backend doesn't provide yet. The former
needs resolving first, as that determines a number of high-level
decisions that will cascade down through the rest of the design.

Current possible solutions include
* Direct interfacing, either via libapt or python-apt (which given the
caching problems - see threads starting at
http://lists.freedesktop.org/archives/packagekit/2007-September/000337.html
and http://lists.freedesktop.org/archives/packagekit/2007-October/000688.html)
may be too slow
* The sqlite-caching implementation currently in there - which has the
problem that the db needs rebuilding whenever there's an update of the
apt cache, but is faster once that's done.
* apt-xapian-index - an external existing caching implementation - not
perfect for our needs (but that *can* be fixed), and much slower on
building initial db, but is damn fast for queries (see
http://aggregator.foolab.org/node/18481)
* Crazy ideas - like using external calls to "egrep" to limit how much
of the apt text files we need to parse (got a partial local
implementation, but it has serious flaws)
* Your idea here.

One option would be building a version that just goes "sod the speed,
let's get something that works first" which could be done relatively
easily with python-apt. This may limit the viable frontends for the
moment, but it might be more important to get something that actually
works first before trying to optimise.... additionally, even if faster
stuff is done, we'll probably still need to use libapt/python-apt for
installing/removing/updating packages and the cache, if only for the
sake of sanity (especially as those operations aren't as speed
critical as querying).

Tom