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.
To read all comments associated with this story, please click here.
Member since:2005-11-13
Exactly. Just like I can have an ODF file on my computer and open it with any word processor that supports the open document standard, so to is needed a package format that is standardized to the point where you could download a single package and use it across multiple distros and package managers.
I don't know why people are opposed to this idea. On one hand, whenever there's a major release of some big package, I see comments on here from people asking why there's no packages available for distro x yet. But on the other hand, many of these same people will claim that different distros reinventing the wheel/duplicating work by creating the same packages is not a problem.
Looks like they've gone from the idea of trying to create a package manager that works across all distros to an abstraction layer. Well, at least they're getting warmer
Edited 2008-10-11 03:33 UTC
Member since:2006-01-11
Member since:2005-07-06
yes, it can be both a problem and a benefit.
but i am of the opinion that if the kde people wants to, they can provide for this splitting themselves, rather then having someone at the distro level overrule their decision.
but then there is a counterexample, xorg, where a "split" into sub-projects have made the updating of drivers and introduction of new features outside of full releases easier, it also puts a bigger workload on the distro level to make sure all the pieces fit together.
so its not a one size fits all, but i firmly believe that the decision rests with the maintainers of the code, not the distros, as to how it should be packaged.
having distros overrule the individual projects just muddies the water even more, as one cant say for sure where the problems originate.
but then i guess one should always report to the distro one uses, and let them handle it. but then that kinda puts one at the mercy of ones distro of choice...
Member since:2005-07-08
While a nice idea in an ideal world, I don't know how realistic it is?
There are dozens of very different GNU/Linux distributions with very different goals. Some have nothing much in common with other distributions except that they use some, maybe heavily modified Linux kernel as a base. As Linux is free and open, the very heterogenous GNU/Linux OS landscape isn't going to change.
Secondly, I think most people would agree that more important than reaching some ideal state where a same package can be installed regardless of a distro, is to make the system stable and make packages work well without having constant system and aplication crashes and other problems. Debian stable achieves the latter goal admirably, because they control everything that goes into it, from package management to individual packages. On the other hand, there have been some distro experiments that tried to implement support for many package standards simultaneously, usually they haven't been very successful nor stable.
As for OS X or Windows kind of software management in the Linux world, nothing prevents distribution designers from building such a Linux distribution too, with their own kind of software management. But that will be just another Linux distribution, and most other distros aren't likely going to follow suit. For example, the Debian and Ubuntu package management has so many advantages that it is very doubtful whether their users would want those distros to change their package management into something like OS X has.
Member since:2008-10-12
Member since:2005-07-06
Member since:2005-08-07
One way to solve that is to simply depend on libs... which most package managers have the ability to do today, so that's not really a big deal...
I'd like to see PackageKit come up with something like OneClickInstall for itself, which I believe is in the process of being done.
This way, you can have PackageKit itself talk directly with the underlying package management suites, and sites can still post single links to download a package.
Lets face it, the package management infrastructure a lot of times is the primary differentiator between distros, take that away, and there is nothing to separate a distro. Maybe PackageKit is a common ground here, and make it so the average user simply doesn't need to care.
Member since:
2005-07-06
they want to present a common interface to the user no matter what distro they happen to be sitting in front of?
while commendable, i dont think this fixes the real issue, that of being able to put one file/link up on some webpage and expect it to install across distros.
common dependencies notation would help a bit, but when one have distros that feel like overruling the original developers in how something should be packaged (iirc, debian slices kde into 1001 different small packages, when the original setup is 5-6 larger ones around specific feature sets), and apply distro specific patches rather wait for them to be processed up stream, it can quite well turn into a never ending mess.