Linked by Rahul on Sat 11th Oct 2008 01:53 UTC
PolishLinux has an interview with the KPackageKit developers. PackageKit is a abstraction layer over the different Linux package management tools. It is primarily designed to unify the graphical tools and provide a consistent distribution neutral framework for application developers to install add-ons as well. This project was initiated and continues to be maintained by Red Hat developer Richard Hughes who also wrote the initial GNOME frontend to it, called gpk-application. Multiple backends currently exist and it is the default for Fedora and Foresight Linux already. Other distributions including Ubuntu, OpenSUSE, Mandriva, and Gentoo are actively participating in the development of different backends. A KDE interface has been under rapid development recently and just did a 1.0 release last week. This interview provides more details.
Thread beginning with comment 333412
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Member since:2005-08-07
PackageKit is not a package manager at all. It still requires the underlying package manager to be able to find the given packages.
Sites and the like will still need to provide RPMs and DEB's and whatever else... PackageKit will just make it easier for the user, and will provide a way to install codecs and plugins in a seamless way across distros - helping application developers.
Member since:2005-11-02
Actually, rpm is supposed to be LSB and universal accross distros, but you guess what? Some distros decided not to install it and not to folow the LSB at all.
Most distributions introduced since the LSB adopted RPM have used RPM. The distributions which "decided" not to use it natively decided this long before there was a LSB: Debian and Slackware. Their derivatives retain that decision, naturally. How many distributions begun from scratch since the introduction of the LSB don't use RPM? Answer that.
The RPM format itself is not much of a problem, though I hear of some complaints about it. There are some issues involved in the RPM database and the rpm(1) toolset. A distribution should, properly, control these things and cannot be beholden to the control of some competing vendor which does not care about the same set of improvements.
What is proposed by packagekit is a lot like the Windows Installer system. It's not mandating the MSI format, or RPM, or DEB. It's mandating an API, a mechanism for installing, updating and removing software. How it works on a technical level is left entirely up to the distributions. You, or rather Microsoft, could implement a back end for Windows which plugs in to the windows update subsystem and uses the same API.
The problem is that it is too easy when abstracting something away to gloss over important details. If you build it with RPM in mind, which is what happened, then perhaps you make it work beautifully and nicely for RPM, but when adding an APT back end you cannot quite get all of APT represented because it has behaviors you did not anticipate. It's an easy trap to fall in to.
Member since:2006-11-17
Most distributions introduced since the LSB adopted RPM have used RPM. The distributions which "decided" not to use it natively decided this long before there was a LSB: Debian and Slackware. Their derivatives retain that decision, naturally. How many distributions begun from scratch since the introduction of the LSB don't use RPM? Answer that.
I can think instantly about quite a few actually. Puppy, Gobolinux, DSL and several other specialized and general distros that appeared after the LSB but decided not to use it.
Anyway, your post makes sense, I wish good luck to the project, and I wish a lot of distros will use it.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2006-11-17
To me, this is just another package manager. That's a big idea: why don't create a package manager that everybody will use and get done with all the different ways of doing the same thing. The big problem is that everytime you have this idea, you create another package manager and there is one more other way to do the exact same thing. In other words, it is not such a great idea, but an addition to the problem.
Actually, rpm is supposed to be LSB and universal accross distros, but you guess what? Some distros decided not to install it and not to folow the LSB at all. Your new package manager or API or whatever does not make sense if not every single distros under the sun have it and it ain't gonna happen.
In my opinion, the right way to go is the alien way.
By the way, it is not a linux problem. Linux doesn't handle or care about packages at all. Linux is a kernel. It's not Mandriva's fault that Windows uses MSI or that OSX uses a strange package format and that debian uses deb files. Linux is not an OS. Mandriva is consistant with Mandriva, Debian is consistant with Debian and red hat is consistant with Red Hat. There is no political problem here. If you see a political problem, that's because you don't understand the difference between a distro and linux. Mandriva or debian is not linux. Linux is the kernel of MAndriva and Debian.