Source: Using PackageKit in GNOME programs
Yet another flamewar has erupted on the internet. (Surprise!)
Backstory:
A while ago Richard Hughes was looking at the various graphical programs for maintaining a desktop linux system (pirut, pup, Yum Extender, KYum, up2date, synaptic, YaST, Zypper, rpmdrake, Smart Package Manager, porthole) and thought there may be a bit of duplication of work going on here, so he started yet another package management framework.
Now he didn't do this just because he didn't like the other applications, but to combine their effort and to start fresh. By developing a common back end and front end for package management a common interface for the users is realized. By rewriting from scratch the interface can be designed to use newer technologies like PolicyKit to provide additional security. With this PackageKit was born.
"PackageKit is a system designed to make installing and updating software on your computer easier. The primary design goal is to unify all the software graphical tools used in different distributions, and use some of the latest technology like PolicyKit to make the process suck less." - PackageKit intro from the PackageKit Site
Well, as you may know, PackageKit has really taken off. It still is rather bare bones, but so far there are 12 different back ends with at least 6 of them in a usable state. For each one of these backends PackageKit presents a common command line, graphical, library, and DBUS API and therefore also be deeply integrated with other applications such as Gnome and KDE.
The offer
So, to help gain interest in this great new library/daemon/gui/API Richard Hughes posted on his blog that he would be willing to code (or help code) package kit based functionality into existing applications.
Imagine, that when you want to install an extension for epiphany you could launch a PackageKit based extension manager that would show you all the extensions available in your distro's repositories and provide all the tools to install, & update these extensions? Now you don't have to leave epiphany to launch a different package management app to install the extension saving you time, and also no matter what backend package system your distro runs (as long as the backend has been coded) the user interface is exactly the same for everyone. This would be a huge leap in usability, and a great idea.
Troll spotted!:
But guess what Jason D. Clinton looked over PackageKit's implementation and declared it to be incompatible with dpkg/apt. But he didn't stop there, he blamed Red Hat for segregating the market by not being able to use anything invented out of house.
Chaos ensued, (as you could imagine.)
A few key points though:
- Richard Hughes started PackageKit before he was hired by Red Hat, so PackageKit is not a Red Hat invention. Red Hat is only guilty of hiring a developer with vision.
Foresight Linux uses PackageKit as their default package manager. If you've ever tried to understand their Conary software packaging system you will soon find out it is unlike anything out there. This proves that PackageKit can be used in systems completely unlike RPM.
Bashing Red Hat like that is unfair. I highly doubt any other company in the world comes close to the contributions Red Hat makes back to Linux and its associated applications/technologies.
Outcome:
I think that tools like PackageKit are the way of the future and it's kind of sad to see such negative press about such a great idea.
The fact that dpkg/apt is designed to allow random terminal input during the package management process is really dumb from a desktop perspective and alternatives should be enforced (such as debconf).
Also, the "problems" with the dpkg/apt backend should be resolved as soon as possible because of the huge political impact. dpkg/apt = Debian = Ubuntu, without those two distributions behind you, your project is really not for every distribution, it is only for distributions that don't use dpgk/apt.
Related:
Rob Taylor's response
PackageKit's Site
Jason D. Clinton's initial post
Jason D. Clinton's follow up post
J.M. Maurer response
Richard Hughes' (the main developer for PackageKit) mocking of the whole issue
Further mocking of the issue by Richard Huges
Havoc Pennington's (past Red Hat and Debian Dev) response
