AppStream/SC/PK GSoC report #1

[Matthias Klumpp]

Hi!
Thanks for the comment!

2012/6/4 Sebastian Heinlein <devel at glatzor.de>:
> Am Montag, den 04.06.2012, 13:47 +0200 schrieb Matthias Klumpp:
>> Hi!
>> [...]
> 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.
AFAIK it was a policy violation at that time too, but I'm not sure...

> [...]
> 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.
Yes, and we can't use python-qpt to access any cache directly when
writing cross-distro software, so we needed another solution. And
btw., we already duplicate the cache in a Xapian DB in Debian ;-)
Right now I am drafting another possible solution for this issue, but
I'll present that later when it got accepted/rejected. (Need to talk
to Richard about the stuff on my whiteboard first)

>> [...]
> The debconf support in PackageKit is KDE only?
What? Who told you that? :D Richard himself implemented the most
important bits in the GNOME frontends and I added the bits for
command-line tools.

>> [...]
> 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.
Yes, and I still think having a fine-grained policy is a good thing -
but we're discussing changes to the API right now, as you know ;-)

>> [...]
> 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.
I'll prove that it's possible :-) And when a new repo is added,
refreshing all shouldn't be a problem: It doesn't take too much time
and if every other repo is refreshed already, the package manager can
skip them to refresh just one.

>> [...]
> Gpk-application and gpk-update-viewer as default applications will be a
> regression in Wheezy compared to software-center in Squeeze.
No :P GPK offers the basic functions which are used very often and
e.g. provides a very nice update-manager. For all other tasks Synaptic
is still available (and default?) in Debian.

> 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.
This is right and I don't have any plans for it - freeze is in a few
weeks, changes like this won't be accepted.
We could always patch GPK to show software-properties-gtk.

Cheers,
   Matthias