[packagekit] Maintainer wanted for PackageKit Apt backend

[Richard Hughes]

On Tue, 2007-10-23 at 19:26 +0200, Tom Parker wrote:
> 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.

Dude, you know my views on work vs. packagekit - thesis always comes
first. Don't worry about feeling guilty :-)

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

Well, we all need to agree, even me...

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

Agree.

> 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

Yes, a search has to complete in less than ~4 seconds - which includes
the setup time. I'm not sure we can do that with libapt.

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

I liked this approach.

> * 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)

Sure, that's a pretty random dep, no?

> * 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)

Yes, it's pretty wack if you ask me.

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

Yes, I think using python-apt and helpers for the non-speed critical
stuff is very sane. The querying _has_ to be quicker.

Richard.