PackageKit gains more and more attention these days: with Pisi and Smart two new backends have been added and PackageKit was discussed at an Ubuntu conference as a possible default package manager.
Richard Hugehes’ PackageKit – a tool for unified package and software management on Linux regardless of the distribution’s backend – was first introduced around July/August this year. Since that it gained an unbelievable development speed and was improved on an almost daily rhythm.
New Backends
Two weeks ago PackageKit released 0.1 version and marked the API as stable. More and more distributions now realize that PackageKit can indeed become what everyone hoped for and start implementing support for the various backends. The last two added backends add support for Smart and Pardus’ PiSi.
The backend matrix currently looks like this:
| PackageKit features and backends matrix | |||||||
|---|---|---|---|---|---|---|---|
| conary | yum | apt | box | alpm | Smart | PiSi | |
| resolve | X | X | X | X | |||
| refresh-cache | X | X | X | X | X | X | |
| get-updates | X | X | X | X | X | ||
| update-system | X | X | X | X | X | ||
| search-name | X | X | X | X | X | X | X |
| search-details | X | X | X | ||||
| search-file | X | X | |||||
| search-group | |||||||
| install-package | X | X | X | X | X | X | |
| install-file | X | X | X | ||||
| remove-package | X | X | X | X | X | X | |
| update-package | X | X | X | X | X | X | |
| get-depends | X | X | X | ||||
| get-requires | X | X | X | ||||
| get-description | X | X | X | X | X | X | |
| get-update-detail | |||||||
| get-repo-list | X | X | X | X | X | ||
| repo-enable | X | X | X | ||||
| repo-set-data | X | ||||||
| cancel-transaction | X | ||||||
Keep in mind that PackageKit was first development for yum and apt. Nowadays other backends are even better supported than yum. In a far future this might even lead to a situation where the backend is developed with the needs and possiblities of PackageKit in the mind. I doubt that any backend developer would like to have the least supported backend if PackageKit gets really wide spread.
PackageKit at Ubuntu conference
PackageKit was also discussed at a recent Ubuntu conference:
The result of this general enthusiasm is that Canonical will likely move forward with the adoption of PackageKit in the near future, although they will need some time to make some adjustments to their own packages first. For example, PackageKit does not permit interactive questions (like agreeing to licenses) during the installation process; dpkg does. As a result, the few remaining .deb’s that still require interactive feedback during install will have to be adjusted to be non-interactive.
The same report also mentions that PackageKit is now widely accepted by rPath distributions. Congrats, PackageKit.
But this discussion also shows the problem between powerful backends and the real world: while it is an interesting feature to have a package/software manager with an interactive mode it is just a feature which is usable by real power users. Normal users cannot answer interactive questions of any kind (maybe licence questions, but that’s it) and therefore distributions which have regular users in their mind should not offer that possibility.
For the same reason PackageKit should not include support for it – it would spoil the entire idea of making the package management easy.
At the moment it looks like PackageKit is the new shining star in the Linux world when it comes to package management. At the moments there are only three things missing to have world domination for it: a zypper backend for OpenSuse, an urpmi backend for Mandriva and a KDE GUI.
/home/liquidat 
> In a far future this might even lead to a situation where the backend is developed with the needs and possiblities of PackageKit in the mind.
PiSi and its yet to be rewritten PyKDE gui (package-manager [1]) is already being developed and updated according to PackageKit. 🙂 PackageKit is indeed a shining star.
We are also working on PolicyKit-KDE which we soon hope to contribute to KDE.
[1]http://www.pardus.org.tr/eng/projects/package-manager/index.html
You write:
But this discussion also shows the problem between powerful backends and the real world: while it is an interesting feature to have a package/software manager with an interactive mode it is just a feature which is usable by real power users. Normal users cannot answer interactive questions of any kind (maybe licence questions, but that’s it) and therefore distributions which have regular users in their mind should not offer that possibility.But this discussion also shows the problem between powerful backends and the real world: while it is an interesting feature to have a package/software manager with an interactive mode it is just a feature which is usable by real power users. Normal users cannot answer interactive questions of any kind (maybe licence questions, but that’s it) and therefore distributions which have regular users in their mind should not offer that possibility.
while I agree that you shouldn’t force ordinary users to answer questions, that’s a far stretch from not offering the option to answer questions. you don’t want to throw out the baby with the badwater
take how debian’s debconf system does this:
– a question is asked at a certain priority,
– you have a priorty setting (critical by default IIRC)
– you only see questions asked at priority higher then or
equal to your own priority setting
this gives the best of both worlds: those who need (or want) more detail get it, while ordinary users don’t
as to “the few packages that still need it” all packages in Debian contain slightly over 10.000 strings, so I don’t really get where the ‘few remaining debs’ comes from (unless perphaps they mean questions of critical/high priority only)
@cobaco
“(unless perphaps they mean questions of critical/high priority only)”
That is exactly what they meant at this meeting. Cheers 🙂
@Faik Uygur: Sweet! As soon as you have some distribution-independent code which I could test please contact me. Also, I would like to know more about your efforts to integrate PolicyKit with KDE. How about an interview or some screenshots? It would be a great way to generate more interest in the KDE community for such a project.
@cobaco: PackageKit is not there to replace apt/deb, but to make life easier for people who don’t need all the fancy features. For these people who still need/want to have such interactive features there is still apt/deb. But PackageKit is not targeted at such people anyway.
Of course, Power Users (like you and me) will have needs far beyond PackageKit, but that’s ok. For that reason PackageKit is just a frontend.
@Troy: thanks btw. for the report, I liked it quite a lot 🙂
Don’t forget that a poldek backend is also missing ;>
and many others backends are mising like KateOS updateos backend ;] But maybe it will change. Also there is no backend for “emerge”
Of coruse other backends are missing as well – but I wanted to highlight the major distributions which are still not included.
About an emerge backend: the idea of PackageKit is to make things easier for average computer users. So whoever cries for an emerge backend for PackageKit shouldn’t use Gentoo in the first place!
ZYpp integration is planned and will be implemented, in fact: http://lists.opensuse.org/yast-devel/2007-10/msg00112.html (a little more info on the thread there).
Francis, thanks for pointing out.
As a stop gap until native support Smart Package Manager can be used in Mandriva and Suse as it supports bath repositories.
XRumer is the best program for advertisement!
It’s have CAPTCHA recognizer, email verificator, and a lot of other functions…
But. I forgot link to it 😦
Can you give me URL to the xrumer description? screenshots, etc.
Thanks