The Unified Package Manager
One of the things which seems to have been reinvented by every version of Unix and every distribution of Linux is the package management system. This post makes suggestions as to the best way of achieving a unified package system.
Why would we bother?
At the moment, quite a lot of time is going into packaging various different pieces of software. Debian has their own set of packaging, as do Fedora and others.
It would be futile to suggest that all distributions use the same set of packaging files. But it would greatly simplify things for software developers if they had some way of packaging their software so that it would be easily installable on every distribuion, and it might help distro developers if every piece of software came with its own packaging setup on which they could build.
What is Package Management?
Above, I've been using the term loosely. But below this point, I want to use some more precise terms:
Package manager: This is tools like dpkg, rpm, and the like. When given a package, they perform an action on it
Package Meta-manager: This is tools like apt, yum, and the like. They perform four tasks:
- Perform actions on packages (much like dpkg, rpm, etc)
- Access repositories
- Resolve dependencies
- Select versions to install
What first
The first thing that needs to happen to create a universal package management tool is to unify the build system. You might be wondering how even this could be done. I have a suggestion as to what to do first: create a universal package specification.
UPS: the Universal Package Specifcation
Say that we call this universal package specification Universal Package Specification (UPS). The initial step would be to gain agreement between the developers of as many packaging systems as possible just what the .ups file format should be. My suggestion is that it should be able to support every feature of every major packaging system, but that all features should be optional except a few that can be agreed upon by everyone.
Anyway, the next step is to write converters to convert this format into the appropriate files for the different packaging systems. In the case of RPM, it would be converted into a .spec file. In the case of DEB (dpkg), it would be converted into a set of files that get put in control.tar.gz. Other package managers can make their own appropriate conversions.
Once this has been done, converters should be written that go the opposite direction. That's right; we want all the different distributions to be able to convert their existing package specifications into .ups format. So we'd need programs with names like spec2ups (for RPM) and control2ups (for DEB).
UPF: Universal Package Format
This will be a more difficult task than the first; agreeing on a universal source and binary packaging format.
For a start, I've noticed that some people have an almost religious feeling for or against rpm, or source-based package managers, or the like. But hopefully with the groundwork laid in the previous steps, these problems can be overcome.
One particular problem is that this will not seem immediately relevant to those who use source-based distributions. But, while the parts that concern binary packaging are indeed irrelevant to them, the parts that concern source packaging are not.
The binary format to be agreed upon should support all the features of the .ups specification; to reiterate, all the features of all the major packaging systems.
To save some effort in comparison, a comparison of the deb, rpm, tgz, and slp package formats already exists.
Unifying the rest of the software
Once the package format is agreed on there will be a few pieces of software to be written. The following should be developed as a collaboration between the developers of existing systems:
- A build system library for ups to upf conversion (libupfbuild?)
- A package management library for ups installation, removal, and upgrade (libupfmanage?)
The two items above could be merged into one if necessary. The individual teams should then develop the next generation of their package management system which calls the libraries above to perform the specified function on the upf files. This generation at least would also be supporting the old package formats, but the new format would be the default.
After a number of years, the package management programs could all be replaced with a single new program that only operates on upf files.
Of course, we could also unify the package meta-manager, but that's a topic for another time.
- wayland's blog
- Login or register to post comments
- Printer-friendly version
Delicious
Digg
StumbleUpon
Propeller
Reddit
Magnoliacom
Newsvine
Furl
Facebook
Google
Yahoo
Technorati
Icerocket
some misinformation and a few problems with this post
Let's start with the misinformation: I'm gonna relate all this stuff to apt and dpkg because i've done the research and it seems to be the best binary package manager out there...It's also the one i know the best as i was an apt/dpkg developer for a shot time and i made one of the most prolific patches in the history of dpkg.
Your description of a meta-manager is just plain wrong. To perform actions on packages, it only acts as a simple frontend to the package manager (dpkg), after you download packages, all it does is call dpkg with the -i switch to install it. Also, it doesn't really resolve dependencies. That's done with another dpkg call which is basically piped back to apt. The closest thing you can consider a meta-manager to be is a REALLY powerful package download tool.
UPS and UPF:
Stating that these need to be created is an over-simplification of the problem. If all distro people would agree on a package format/spec, one would exist. If everyone agreed, every distro would already use deb or rpm or .tgz, etc, but they don't because the people on the distros can't agree upon anything. RPM is the WORST package format out there according to 90% of linux gurus, yet it hasn't even been replaced yet.
Which package formats have what: DEB = good dependency management, excellent compression, good compatibility, difficult to create proper packages. RPM = HORRIBLE dependency management, decent compression, bad compatibility between versions/RPM distros, not too hard to create proper packages. .tgz = barely a package manager, i'm not counting it .pkg.tar.gz (Archlinux) = good dependency management, decent compression, good compatibility and VERY easy to create proper packages.
The optimal solution: First, just let me say, i am currently working on this. It is not on sourceforge or anything, but when it's usable it will be.
A universal package manager done right. It's one package manager (well...a manager and a meta-manager) that supports every package format (rpm, deb, .tgz, .pkg.tar.gz and ebuilds) and they all work the same way: upm -i firefox_2.0.0.12-1.deb or upm -i firefox_2.0.0.12-1.pkg.tar.gz ...They'd both install Firefox either from a .deb or a .pkg.tar.gz...This already somewhat exists with alien, but my plan is to not have to go through the messy process of conversion.
Now, the meta manager...The meta manager would support all different repos (Debian/Ubuntu with deb and deb-src at the beginning of a line of the sources.list, Fedora/RH with yum at the beginning of a line, Archlinux with Arch at the beginning of a line, etc) and if let's say you wanted to install firefox from different repos: upmm --apt install firefox upmm --yum install firefox upmm --arch install firefox, you get the idea. By default, if Ubuntu had something like this in the distro as the default package manager, there could only be deb sources in the sources.list and you could add a file with what type of repos to pull from by default when the user adds more repos.
PackageKit: PackageKit has the same idea that i just posed above except it can't handle multiple formats "at once". However, in theory, PackageKit is supposed to eventually support most package meta-managers and managers so that you get 1 nice GUI or CLI frontend on any distro so you never have to learn a different package manager if you go distro hopping. The current problem with this is, however, that currently PackageKit only supports yum well and all other package management system support is below sub-par. Also, it supports obscure package managers like box and zypper and pisi, but not some of the more mainstream ones like Portage and Pacman and Ports.
Pretty much right
I'm not sure "misinformation" is the right word, but what you say is true. I should've clarified that a package meta-manager sits on top of the package manager, and depending on the setup, either runs the package manager to get it to do stuff for it, or calls the same library that the package manager does which implements most of the functionality.
Also, I admit my main familiarity is with RPM and the associated tools.
I think the reasons that everyone sits on their own package manager are: 1) They already have a lot of effort invested into their current setup; this means that they don't want to reimplement their spec files in a different system 2) They can't convert to a different system becase it doesn't have all the features that they want.
The package manager's features are important to them, but not nearly as important as their existing "codebase" of files. Unless you have a 100% automatic conversion tool, it won't get used. If you don't support all features (such as RPM triggers), you won't be able to 100% automatic conversion.
I like your goals for the meta-manager, but I think you risk running into strange dependancy problems when pulling packages from multiple distros. For example, you might have bind installed, but a package from another distro complains because it can't find named.
You may enjoy the next post in the Package Management series (and the last post for now, I think), because it's about Package Meta-Managers.
Basically, I think we're trying to solve different problems. The problem you're attempting to solve is that its sometimes hard to find a package of the software that you want. The problem I'm trying to solve is the duplication of effort caused by different people creating packages using different package managers.