AppStream/SC/PK GSoC report #1

[Sebastian Heinlein]

Am Montag, den 04.06.2012, 13:47 +0200 schrieb Matthias Klumpp: 
> Hi!
> 
> 2012/6/4 Raphael Hertzog <raphael at ouaza.com>:
> > Le lundi 04 juin 2012, Matthias Klumpp a écrit :
> >> If you read through this now, I'd like to ask you if you have anything
> >> you want to do with PackageKit (which is not very backend-specific)
> >> and haven't been able to do until now. - If there is any of these
> >> issues, we might now be able to fix it.
> >
> > I'm not involved in all this but there are reasons (which I don't know)
> > explaining why aptdaemon got introduced when the natural choice should
> > have been to decide to use PK.

Back in those times we tried to convince Richard about the need for
debconf, config file conflicts and terminal interaction but he wasn't
willing to change his policy. (The terminal interaction one was required
at those time but nowadays is a Debian policy violation - but there are
also tools like apt-listchanges or apt-listbugs which still depend on a
working terminal).

It is indeed a shame that we could not find a solution at that time and
that the policy of PackageKit was changed later.

I still believe that it is more important to share common interfaces and
not the implementation of those. In the beginning the idea was that the
session interface of PackageKit would be the entry point for third-party
software. But over the years thanks to the great GObject introspection
the use of the PackageKit glib client spread. That is why aptdaemon now
features a PackageKit compatibility layer. It allows for example to
query for updates, install codecs or install updates with aptdaemon by
only using the PackageKit library on the client side - and doesn't block
the adoption of the PackageKit interface on Ubuntu/Debian. The compat
interface now even supports more PackageKit transaction types than the
aptcc backend of PackageKit itself (but the query transactions aren't as
fast as the aptcc ones for results with a huge number of packages but
the importance of those seem to decrease - see next paragraph). Even
Unity now uses the PackageKit interface in 12.04.

Furthermore PackageKit only allows to process one transaction at a time.
So you cannot query the package manager for e.g. the description of a
package while another transaction (e.g. system upgrade) is running.
This isn't supported by aptdaemon too, but the approach to the problem
was having a cache on the client side. Software-center directly access
python-apt. Aptdaemon originally only covered all operations which
required root privileges. The PackageKit approach with the GSoC project
of Matthias is currently to nearly "duplicate" the native package
manager cache in a SQL database and use this in software-center.

> The reason why aptd was introduced was that PK wasn't able to fulfill
> some special Debian/Ubuntu requirements, for example Debconf support.
> Debconf is a very flexible system to ask questions during installation
> of packages, something which PK explicitly forbids by policy. (See
> hughsie's law) We (mostly Daniel, I did a few things too) managed to
> workaround this issue last year.

The debconf support in PackageKit is KDE only?

> Also, aptd only has one PolicyKit policy to do all actions and a DBus
> interface to perform actions on, allowing some more advanced tools to
> use aptd too. Right now, something similar is discussed, but it's a
> very slow discussion.

To make it clearer: Aptdaemon features a combined
install-or-remove-packages privilege and a method which allows to
install, update, remove, purge and downgrade packages at the same time.
Currently PackageKit only allows to install, remove and update packages
in separate transactions in a row.

> Last but not least, aptd supports some Ubuntu specifics (purchasing
> apps, plugins) and does some other things which are more or less
> covered by PK already.
> 
> > Have you looked into those reasons and can PK fulfill everything
> > that aptdaemon does?
> Right now, PK can do some stuff aptd can't and aptd can do things PK can't.
> In theory, PK can do everything Aptd can, if some API changes are
> made, and this needs to be discussed with Richard, who usually has
> some good comments about that changes.

Software-center requires to get the small things right to provide it is
good user experience. And this is very hard by using a generic API as
the PackageKit one: E.g. after a new repository was added we only want
to only download the list of available packages from the added
repository and not from all. So there will always be some special
requirements for software-center on Ubuntu.

> > It would be great to have a cross-distro solution that's really
> > cross-distro and that does not force everybody into the lowest common
> > denominator.
> Agreed :-) At least we managed to get all stuff ready for Debian now,
> and I'm happy that PK will be part of the new Wheezy release. (You can
> already try it there!) PK is fully functional in Debian, there are
> just some things missing I need to implement the SC properly.

We failed to update the software-center stack to the latest releases
(Precise) for Debian in the time frame for wheezy. I will try to get in
a newer release of aptdaemon. But the version of software-center in
Debian is working (it is basically the one of the Oneiric release). It
would have been a good idea to replace update-manager by the Ubuntu one,
since the Debian fork isn't maintained anymore and requires to be
executed as root.

Gpk-application and gpk-update-viewer as default applications will be a
regression in Wheezy compared to software-center in Squeeze. Even
editing repositories (the sources.list in Debian terms) will be at the
same basic level as 5 years ago if software-properties goes away from
the default install. Shipping a software-center with a working
PackageKit backend cannot be done and stabilized before the freeze.

Cheers,

Sebastian