Hi! Thanks for the comment! 2012/6/4 Sebastian Heinlein <de...@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 _______________________________________________ Distributions mailing list Distributions@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/distributions