Am Montag, den 04.06.2012, 13:47 +0200 schrieb Matthias Klumpp: > Hi! > > 2012/6/4 Raphael Hertzog <raph...@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 _______________________________________________ Distributions mailing list Distributions@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/distributions