Slashdot Mirror
The State of Linux Package Managers
I was pointed over to an editorial that is currently running on freshmeat. The author of the editorial takes issue with the current state of package managers for Linux and proposes a way to fix inadequacies. Here's a sample of the solution: "The solution to the problem seems to be to extend the autoconf
approach to package systems.
This requires providing the necessary tools, standards, and guidelines to
software and/or package authors to
enable a single source package to produce a wide variety of binary packages
for the various platforms and
packaging systems."
What needs done is much simpler. Currently popular packaging systems need dumped in favor of GNU Stow. Then we don't need to change automake and autoconf at all, because they work as-is.
Dependencies could be added to Stow by someone without a lot of trouble.
For those who don't want to download and install it to figure out what it does (althoug you should! It makes life very easy if you do any source installs), GNU Stow takes "packages" that have been installed in the standard manner (things placed properly in bin, lib, man, etc.) in their own directories (such as /usr/local/stow/) and makes links to the parent directory's bin, lib, etc. You can tell by a simple ls -l what a file belongs to. Since the links in the directories aren't the "real" files, you can delete and restore them with minimal trouble (I challenge someone with a conventional system to rm -rf /lib and restore it, without rebooting). You can even maintain multiple simultaneous versions of packages. Autoconf already makes this easy to use, simply supply the --prefix= parameter to your configure scripts.
No silly proprietary formats, nor waiting for someone to come out with the latest package in your favorite format, no trying to convert foreign packages to your system. Everything you can find in a tarball is now pre-packaged and waiting for you to install...
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
This solution is very similar, but a little different to the /usr/ports solution in BSD. It would be easier to build this autoconf idea on top of ports than on top of the existing package managers, because they're already very similar.
/usr/ports/graphics/gimp ; make install" and away it goes--it downloads gimp from wherever it needs to, notices that it depends on GTK so it downloads that, etc., and builds each thing it needs in a giant make script until the whole thing is installed on the machine.
/usr/ports solution.
Brief intro for those unfamiliar with *BSD: To install "gimp" on FreeBSD you do this: "cd
The FreshMeat editorial makes it sound like this is a brand new cool idea--it's not, all of the *BSD's have worked this way for years. I really like it.
I would love to see Linux support something like this. The closest is Debian's apt, which has a mode for fetching and installing from source, but it's not as simple and direct as this
Some comments on this way of doing things:
-- I *love* being able to browse through the filesystem to find out what packages I could possibly install. It's a very natural thing to do: if I want to browse graphically, I do so via netscape or some filemanger. Mostly, being a geek, I use "ls", "cd", and "locate" to find out what packages i might want to install.
-- It's less to learn. If you are already going to have to learn how to do "make install" in order to get packages installed outside of your package management system (you just HAVE to have the version released yesterday) then you have already learned what you need to know to install any other package.
-- It does support a binary packages system. Binary packages amount to doing the compile stage on someone else's server, the whole install process goes exaclty the same way except that ratehr than compiling the binaries, you fetch them.
-- It brings everyone closer to the source tree. It's natural to grow up from being a novice user, to being a bit of a code hacker. There the code is, in front of your face, begging you to look at it--many people say this will scare people off, but nothing *requires* you to look at the code; and it's incredibly tempting for the curious. I think this leads to more developers, and is the main reason why *BSD has been able to keep pace with Linux despite having many fewer users.
-- The filesystem is a concrete, easy to understand organization for the packages. I can visualize where things are and how they relate to one another. With other package managers, like RPM or DEB, the dependencies seem complicated and abstract. When there is a failure, I haven't got a clue what to do (well I do now, but I didn't used to). AT least with compiling when there is a failure I can kind of see that it is a file in this package that lives over here, and that is causing my problem. I may not know what to do, but I know where the problem "lives". This makes me a little more motivated ot try and fix it, possibly by trying to install that other package some different way or something. In theory deb is the same, but it just doesn't *feel* the same.
In my opinion the only package management approaches that anyone should seriously consider are the Debian approach (apt/dpkg) and the *BSD appraoch (ports, plus their package management tools that back it up). Both of these allow all kinds of fun stuff like upgrading your system live without rebooting; synchronizing on a daily basis with the most current version; and have intricate and strong concepts of dependencies between packages.
In theory, they are functionally equivalent--or close enough--but I prefer the filesystem based implementation that has source code at its heart. It not only seems more Unix-like to me, it seems more open.
The big counter-argument to all of this is that source is scary to average users, many of whom don't understand the filesystem at all. I figure this is no argument at all, because you can bury the compilation under a pretty GUI just as easily as any other dependency system. And if your user can't figure out a filesystem, they won't be installing stuff using *any* package manager: it'll be pre-installed, or nothing, for them.
Just my $0.02