[packagekit] Res: New backend

[Sebastian Heinlein]

Am Montag, den 05.01.2009, 05:31 -0800 schrieb Daniel Nicoletti:

> >Do you refer to the debconf/configuration conflict handling? These
> are
> >not problems which can be solved in the backend, but require changes
> in
> >PackageKit's design for a proper integration. I get the feeling that
> >apt doesn't fit very well in the PackageKit framework and we have to
> >add a lot of workarounds.
> 
> i know it's not completely up to the backend but
> i have some ideas that would be easy for me to do/test
> if the backend was in c++, i'll take a look at your
> dbus daemon but i don't know apt enough for that, and
> that's another reason i started to write one..

The problem is the non interactiveness of a running PackageKit
transaction:

- no conflict resolving of configuration files
- no media support (cdrom/dvd)
- no debconf support

The main issue of the python backend implementation is currently the
speed of sending a large list of packages. GetPackages is very slow
compared to the spawned backends. This could be a problem in the
dbus-backend or the python backend code. I turned the dbus apt backend
into a spawned one for testing sometime ago and it was as fast as the
other ones.

> it's going fast with the search stuff, i have searchName
> fully working, + resolving the virtual packages which
> i find very usefull, the next step will be sorting
> the packages (right now without sorting the time is
> half of py bkend). getDetails is complete too + localized
> (apart from the license). getPackages, getGroups and filters
> are working too. this week i plan to sort the output
> and finish getRequired getDepends. All methods are now
> threaded too.

Actually the speed of the search name method seems to be sufficient for
me already and not to be an important area for improvements. By the way
the python backend already sorts the results, to report them in
alphabetic order to the packagekit daemon: gpk-application sorts the
packages only by name and so we get a lot of flickering if they are not
reported in alphabetical order.

For the SearchDetails method we make optionally use of apt-xapian-index
which is really fast. One problem of apt-xapian-index is the
synchronization after a cache refresh, that takes quite some time
currently. The potential of a-x-i is not yet used: it allows to reinject
the search by taking the debtags of the first results into account. So
searching for a "graphics editor" would give you back gimp (image
editor). And this with nearly instant results.

The only chance for supporting the license information in the apt
backend will be the implementation of the machine readable copyright
files proposal and an automatic tagging based on this. But this will
take some time - although this is a highly requested need of OEM
vendors.

The biggest advantage of a Python backend is the maintainability. Do you
have got any plans for a testing infrastructure? I started writing one
using python-mox - which is really an awesome piece of code and a great
help. It is a shame not having a testing infrastructure before.

Learning python is not hard. You could do this in a week. There are even
some Python-in-24-hours tutorials :) Also python-apt could be a nice
working place for a c-coder.

It would be nice if you could share some more of your ideas. Since for
me it won't make sense to work on a Python backend if you can provide a
better one written in C++.

Cheers,

Sebastian