Ladislav Bodnar examines the package management tools in five major binary Linux distributions (Debian, Mandrake, Red Hat, Slackware, SuSE) and provide examples of 1) installing a package not officially supplied by the distribution itself and 2) upgrading the entire distribution to a newer version.
The Great Package Management Experiment
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’m surprised they excluded Gentoo and FreeBSDs package management systems.
For the intermediate to advanced user, these CLI tools are perfect. No fuss, just software. However, the author did not mention the fact that there are GUI front-ends to these tools, like Synaptic. With these tools, stuff that is utterly painful in Windows (you never understand until you try automagic package management how dreadfully manual the Windows installer scheme is) become easy. It takes me literally 2 seconds of my time to upgrade to a new version of Gentoo. In that time, you probably can’t even open the WinXP SE box…
Its a shame that RedHat is so behind the times. I consider theirs one of the best distributions available today in the “no hassle” department. If RedHat would install Synaptic and apt4rpm by default, the usability of the OS would go *way* up.
It is clearly written in the article that the author went after the 5 biggest distros. Gentoo is currently No6, after (but close) to Slackware, in “linux marketshare”.
The main reason for leaving out Gentoo was my insatiable desire to see how many Gentoo users will come to this forum and start screaming “UNFAIR”.
Seriously though, I stated in the first paragraph that I would compare the five major binary Linux distributions. Installing binary packages is fundamentally different from compiling directly from source, so I felt that Gentoo would be a black sheep on the list. Besides, I only had three days to complete the story – barely enough for installing Gentoo, let alone for doing time-consuming system updates over the Internet.
…too bad, as it is a very promising project (although there are only three packages available, Mplayer is actually one of them).
From the website:
What is autopackage?
autopackage is software that lets you create software packages for Linux that will install on any distribution, can be interactive, can automatically resolve dependencies and can be installed using multiple front ends, for instance from the command line or from a graphical interface.
Give it a try – and if you’re a software creator, you should consider testing your software with it:
http://autopackage.org/index.html
For those of us who have system locales set to some other language than English, Debian package management has the added advantage that it tries to find for every installed program the language settings that match the system locales. For instance, in my Debian box I got Finnish menus to the latest version of OpenOffice.org. No such luxury in Slackware, FreeBSD, or Windows.
(Locales are set in Debian with the command ‘dpkg-reconfigure locales’.)
Seems like the article says that apt-get is the best way to install packages. Debian users around the world go “Duh!”
😉
I had high hopes for this article, but it quickly turned into avoidance of standard tools.
Why bother doing a comparison like this? Use the standard tools!
While you can graft apt onto any distro, some really useful information could have come out of a real comparison of the various package managers.
Use Red Hat’s worthless update tool that leaves your system unbootable from time to time. And Don’t they include GPackage, too?
Slackware doesn’t advise use of swaret, that’s a third party app. Show the real headaches of doing the work a computer should do. I’m posting this from Slack, BTW.
Why didn’t he just use YOU on SuSE?
They should have used Gentoo. I’d hate to see the time comparison between installing a binary and recompiling something on Gentoo though.
FreeBSD really should have been there. FreeBSD works so well with so little good press.
Throw in a tar.gz source file just for kicks. I’m sure MPlayer would miss something in the configure step that would require searching for more source code.
Time the searches for the dependencies. Not a bad idea for any of the package managers. Searching for dependencies is where most of the users time is spent in many of the distros.
I’m sure I’m missing a quite a few too, but then again there is almost more of a comparison in this post than in the article.
Mutiny
As a system for binary packages, the dpkg/APT combo wins hands down. However, when it comes to custom packages, I’ve realized that Debian simply sucks.
For example, I was using a custom repository for a while that had KDE CVS packages. Unfortunately, the packager decided at some time to add a dependency on the XFree86 CVS, which would have required yet another custom repository – one that I didn’t want to try. Worse situations can be imagined, where custom repositories actually depend on conflicting secondary custom repositories. I could go on to a rant about why conflicting packages *must not* exist, but to anybody who really thinks about this subject, that should be obvious.
Eventually, I think autopackage is the Right Way. I’ve tried it, and it looks very promising.
For the time being, however, I’ve finally found my (almost) dream come true, though, and it’s really amazingly simple:
Compile from source – but don’t install into /usr/ or /usr/local/ – instead, install into /usr/local/packages/$NAME-$VERSION/, and use Stow to automatically create symlinks in /usr/local. It works, and it works well for most things. Unfortunately, running something as big and full of fundamental libraries like KDE CVS using this system sounds like a real nightmare – again. *sigh*
Besides, I only had three days to complete the story – barely enough for installing Gentoo, let alone for doing time-consuming system updates over the Internet.
OUCH!! You went for blood!
…there is almost more of a comparison in this post than in the article.
Oh, absolutely.
Next time we’ll switch the roles – you spend an entire weekend doing the tests and writing the article, while I’ll be lying on the beach sipping beer and checking out the girls. Then on Monday I’ll get back to the office, read your story and rip it apart in a 5 minute forum post during my tea break.
Deal?
How lame to call a package that is included in an official repository “third-party”. The real problem with all those tools is, that it’s often not simple to install _real_ third party applications and if it is, then you often don’t find a working package for exactly your distribution.
Don’t tell me that all software is available from such repositories, that’s simply not true. It’s only true for very common software, usually not for new or rare software. This method also scales extremely badly (we don’t have _that_ much software yet).
Autopackage is seriously one of the very few ways I see out of this trouble. I hope they’ll soon be able to get at least game developers to use their system (the old Loki installer doesn’t quite cut it anymore) and those who usually provide distribution independant installers anyway (OpenOffice, Mozilla, …).
Portage is also nice but only for Geeks and Free Software (you can’t compile proprietary software usually :p and then you get the same trouble as with any other distribution).
Mandrake *DOES* include mplayer in the distro… much in the same way SUSE does except the plf packages seamlessly install.
Take it easy, I think it was a valid point.
I’m not trying to justify people slamming articles, but you have to expect a litle criticism.
Why use debian’s packagetool to compare Red Hat’s packaging? Red Hat does not, by default use apt.
SuSE, does not, BY DEFAULT, use apt.
Slackware, does not, BY DEFAULT, use apt.
Heck, why didn’t you install apt-rpm on Mandrake? It is available and therefore the packagemanager to use by your logic.
Should I go on?
Mutiny
Oops, I meant to say that Slackware does not by default use swaret.
An edit or preview button would be really nice.
Mutiny
I’m an Mac user but since i got this old Pentium II i say, go debian.. with the help of debian i got a full working web server, bittorrent server and a nice desktop with Xfce4 running Firebird, Thunderbird, gaim, mplayer, xmms and nautilus and The Gimp 1.3 ..my Mac is almost obsolete and that for only $ 0,- ..or 0,- euros where i’m from. However i’m pretty impressed by Panther (Mac OS 10.3) and the new G5 i think my next PC will be running debian, even if it’s a Mac!
apt-get install a very powerfull server and a very nice desktop
..very nice overview
Interesting on how to upgrade Mandrake. I’ll have to try that.
Also interesting how much SUSE has fallen behind. Only a year ago you would nothing but glowing reports about SUSE.
RedHat made the right move, recently, in opening up their desktop development. I expect it won’t be long before they catch up to Mandrake and Debian.
Slackware – no comment.
Autopackage? I’d love to see this catch on.
Is that some distributions which actually seem to offer a choice on how to do it seem to have suffered as a result.
People who want to be able to do dist-upgrade and the like are not usually stumped by ‘where to get yum, apt” or whatever tey need to do that.
What is the real value of being able to upgrade using apt-get anyway. It is mostly useful if you have no third party packages anyway, you run into problems if you have third party packages. Upgrading on a vanilla installation is pointless IMO. Why not just install the new thing right away. I am sure if you installed Ximian Packages on mandrake (If they existed), you would have major problems upgrading. Most of the author’s problems with packaging comes from not having good package policies to begin with. Which is what Fedora, for example, set out to do first. Providing guidelines and good build tools.
Slackware’s tgz does very very well what it’s meant to be. Nothing more and nothing left.
If you don’t want to know about your system dependicies than it’s nothing for you.
With swaret you get a nice tool to have an up2date system with a minimal dependicies check.
It’s great, I love Slackware because I want to know my what I’ve installed on my system. Don’t want only to know that I have only mplayer installed…
I give Slackware a 10+!
And like I don’t know whats on my system and what depends on what. When I really need to get something done quicky it’s just not a geeky quagmire.. I have the choice. I don’t have to use urpmi.. I can just toy with rpm if I want…
From what I’ve seen of the Slackware way of doing things is to install an app… watch it not load… then guess about what is missing.. then try another etc. A very painful process… might as well try LFS.
Besides, I only had three days to complete the story – barely enough for installing Gentoo, let alone for doing time-consuming system updates over the Internet.
Gentoo only takes about an hour if you do it from stage3 which would give you the equivalent of a debian install. I built gentoo (stage 1) on my XP 2500+ in under 9 hours. Thats everything from source, and download time!
I also agree with what’s been said above, why compare apt to apt? If you are going to install apt on every distro just go with debian! Might as well install rpm into gentoo/debian/slack and use it for package management
If urpmi was available on Debian and a portion of people used it because for some reason apt was not good enough, then it would be urpmi vs urpmi… so freaken what? he is comparing the distros also… not just the package managers.
Also. he is not “going” with these distros.. he is NOT choosing sides… he is providing a review.
No, it wasn’t an article on the comparison of distros. He’s sitting there handing out ratings based on what? Using 3rd party tools for doing package management?
I could easily hand Debian a 0 in package management if I reviewed Debian the way he reviewed the Red Hat or SuSE systems. Oh damn, Debian can’t handle YaST. That’s a 0 for Debian.
That is what his article is essentially saying.
Never had a problem with RedHats up2date of course i had to pay $60 to get it to run without a hitch. Also it complains about a bad ceritifcate now? REBUILD but when it did work it was flawless.
As far as package managers go, when they work, they’re golden. And when you can actually find a particular version of the app your looking for in the repository, they’re golden.
However, I have found that the latter is a much bigger problem than the former. I have found that even with the 80,000 or so packages that are in a repository, they seem to have every package imaginable .. except for the one I’m looking for. And if you can’t find a .deb, .tgz, or whatever of the app you want to install, then it’s back to configure/make/make install, which generally has a much higher rate of failure than the package managers.
That’s what I like about Win32 – as tedious as installshield wizards are, I can take comfort in the fact that 99% of the time, I can always get the latest version right off of the application homepage. I don’t have to deal with only having the source, and/or having to worry about whether there is a package for my distro of choice. And, I very rarely EVER have an install that just flat out doesn’t work.
My proposed solution to this problem – create a standard for all package managers to follow. And I don’t mean like apt or RPM as a standard (as they are package managers, not standards) .. I mean a standard like HTML is to the WWWW. You could define things like package information will be located in a directory called /packages (or whatever). Then, you could use ANY package manager you wanted and could be reasonably assured that they would be compatible, as long as they followed the stanard.
😛 …that’s just too funny!
“No, it wasn’t an article on the comparison of distros. He’s sitting there handing out ratings based on what? Using 3rd party tools for doing package management?”
You would not like the review more if he didn’t include those “3rd party” tools in it. And people would be ranting and raving about it also. So he did what was reasonable. He reviewed the package management opertunities provided by the distros and he took off points if you had to go out of your way to get decent tools. Ofcourse that involves comparing the distros.
“I could easily hand Debian a 0 in package management if I reviewed Debian the way he reviewed the Red Hat or SuSE systems. Oh damn, Debian can’t handle YaST. That’s a 0 for Debian.”
Don’t be silly.
Sorry but that is just not in the cards… it costs money to make a cd for every app and it takes space to compile all your deps in to the app. OSS just does not have the money to do that. Things generally go the way of least resistance and that is what OSS has generally done. Afterall people don’t pay for the apps in the same way they do for win32 apps. Not to say anyone is cheap but if you give your things away, people will be less likely to pay for them. And different systems will develop as a result.
Sorry but that is just not in the cards… it costs money to make a cd for every app and it takes space to compile all your deps in to the app.
Don’t know if you were replying to my post, but I said nothing about building all deps into your app. I said buuild a standard around package mamagent, so that way, instead of having to have the source code on the home page and usually at least two seperate binaries (Redhat/Suse RPMs, and maybe a .deb if you’re lucky), you could simply have one file for the source code, and then another file with the package manager of your choice, thereby DECREASING the space/bandwidth.
Well, in theory, RPM is the standard. And commercial software vendors (Alias/Wavefront, etc) use it as such. This isn’t a big deal, because most any distro can access RPMs these days. Sure, it doesn’t to automagic dependency resolution, but neither does InstallShield.
@Spark: Portage handles binary packages just fine. For example, most people use the binary packages of OOo because OOo just takes so damn long to compile. Also, lots of stable software is available as binary packages via the GRP. The nice thing about Portage is that ebuilds are fully programmable, so lots of stuff that doesn’t fit into the usual model (epsxe or vmware, for example) are still installable through Portage. As for the coverage of various apps — I think that for 99% of a person’s software needs, a centralized repository can handle it. I’ve only got a few programs (for example, OmniORB) that I didn’t install through Portage. Even when something is a bit out-of-date, its usually trivial to edit the ebuild to get the latest version.
I was replying to the wonders of win32 more then anything.. Sorry about that but when I latch onto an issue.. but regarding standards… I don’t know if any exist but the LSB should work to the same end in that the ultimate goal I guess would be that you should just be able to grab rpm or apt etc. and install any binary package on your distro.
Some packages allow you to “make rpm” or I’m assuming other package types and there is also checkinstall wich kinda elminates the need for that second file.. sorta.. but it would be neat if that second file would be a complete script to download, compile and install(in the native package format) a program. You could have one for each distro to download or perhaps just roll this all into one grand packaging program.
Why compare apt to apt ?
Simple, because more than a few people use apt or its
variants to install software packages on these Distros.
As to why they do that, by now you think the answer would
be well known: apt is great.
Besides this way he can compare apptles to apptles.
This would mean these plugins would know how to work urpmi or apt or gentoo…
What you’re describing is exactly what autopackage is trying to achieve. You can already test it with a few apps (go to the Download section of their web site).
Well, in theory, RPM is the standard. And commercial software vendors (Alias/Wavefront, etc) use it as such.
Sorry, but RPM is not a standard – it’s a package manager that people are trying to make into a standard. AFAIK, a standard is not an implementation. For example, when ANSI/ISO set out to make a C++ standard, they didn’t make a compiler and say “Ok, here’s the standard ..” No, they came out with a list of specifications that dictated how compilers should interpret source code.
As for autopackage, according to the autopackage web site:
autopackage is software that lets you create software packages for Linux that will install on any distribution, can be interactive, can automatically resolve dependencies and can be installed using multiple front ends, for instance from the command line or from a graphical interface.
Again, it appears that they’re not trying to define a standard here, but simply trying to create a standard package manager, not the same thing … unless I am misinterpreting whaat autopackage actually is.
“You would not like the review more if he didn’t include those “3rd party” tools in it. And people would be ranting and raving about it also.”
Yes, I would have. It would have been nice to see what other distros offer. But here I am, and all I see is apt like systems all over the place. Now granted, apt like systems aren’t bad, but it has it’s own problems.
He’s the one who claimed to be doing a review on package management systems on the various systems. Really, all he did was compare apt on the various systems. What he was trying to do, and what he did, was complete different. To think otherwise is to be a blind sheep.
“So he did what was reasonable. He reviewed the package management opertunities provided by the distros and he took off points if you had to go out of your way to get decent tools. Ofcourse that involves comparing the distros.”
No, he didn’t. He didn’t, and any contention otherwise is an outright lie. He didn’t review the package managers of the system. I actually read the article, and he didn’t. I’m not complaining about which distro ‘won’ (apt is really, really nice, afterall), but what the article does is nothing more than give a few geeks intellectual orgasms because they are using the “distro that won.” If that is all it was intended to do, that’s fine. But to claim anything else is again, being a blind sheep.
Just in case I haven’t made myself clear, what I am invisioning is that a binary package would be something like a zip file. When I download a zip file, I can open it with Winzip, Winrar, Power Archiver, CuteZip, PKZip, whatever. I don’t need program xyz to open the zip file because there is a standard that dictates the zip file format.
Similarly, if I download a package, assuming there was a standard in place, I should be able to install it with apt, portage, RPM, or any package manager that you throw at me. So, the trick is not to derive a standard around a particular package manager, but to determine the exact way in which packages are formatted, installed, and how dependencies are resolved, and THEN have everyone agree on it. Then, every distro can still have its own package manager, but a standard would ensure that a package would work with ANY package manager that follows that standard.
Again, it appears that they’re not trying to define a standard here, but simply trying to create a standard package manager, not the same thing … unless I am misinterpreting whaat autopackage actually is.
Huh…you lost me there. What autopackage does is create a single installable file (think of a setup.exe file in Windows) that can be dowloaded and installed on any Linux system, regardless of the distro used. I don’t know if that’s what you would consider a standard, but it would solve a lot of the problems people associate with not having a standard…
I love this thing ! Not to mention that TexStar is the patron saint of Mandrake users.
Portage handles binary packages just fine. For example, most people use the binary packages of OOo because OOo just takes so damn long to compile.
I didn’t say that Portage can’t handle binary packages, but then it isn’t better than any other current solution (read: bad).
As for the coverage of various apps — I think that for 99% of a person’s software needs, a centralized repository can handle it.
But in reality, it’s this 1% that is the problem. I have used APT, Portage and others for years and can absolutely see why it just isn’t sufficient for average heavy computer users (think gamer, think computer freak).
Even when something is a bit out-of-date, its usually trivial to edit the ebuild to get the latest version.
That is exactly why I mentioned Portage as another interesting solution. Even if there is no ebuild at all, you could just compile the source of the software. But as a matter of fact, this only works well for geeks and with Open Source software.
Software installation is one of the more interesting problems IMO, especially in an “open” environment. There has to be a solution in the future for third party developers to deliver convenient binary packages which work on every distribution which fullfills the requirements of this software. Meanwhile I’m convinced, that the solution is two-fold: Central repositories and tools like RPM/APT/Portage are ideal to upgrade core parts of the distribution, for system installation, etc. But there should be someting like Autopackage which allows a developer to make convenient binary releases which work on every supported plattform. It just can’t be that you are forced to run several differnt versions of countless distributions just to offer binary packages to all your users.
Not sure if that last part made sense, I’m tired now…
But there should be someting like Autopackage which allows a developer to make convenient binary releases which work on every supported plattform.
You mean, something like Autopackage? 🙂 Why would you say that something like Autopackage is needed, when Autopackage is already available – although still in development, it works pretty well and is distro-agnostic.
Something like Autopackage is here, and it’s called Autopackage. Now developers only need to start using it.
Why didn’t he install apt on Mandrake then?
The thing that I like about portage is not that I can get everything super-optimized, but because I can build binaries with foobar support, or without foobar support. For example building the Openbox window manager without Gnome support. This is a performance advatage worth the compile time IMHO.
Don’t get me wrong, binary package systems are great, and it’s good to see the RPM distro’s enhancing their package functionality. This review does a great job at it’s stated goal of reviewing binary package managers! I learned of new Slack package managers. Thank you.
However in a large environment when implementing software with available source, it’s almost futile not to use distros like Gentoo, Sorceror & knockoffs, as well as the excellent BSD systems. Things like optimized package building and distributed compiling are worth it in this situation. Sure you can pay <insert commercial free software company here> to optimize your environment, but honestly why not just do it yourself? Afterall, who needs KDE/GNOME compiled support for an internet kiosk running mozilla?
“Huh…you lost me there. What autopackage does is create a single installable file (think of a setup.exe file in Windows)”
Actually it isn’t. A .package is definitely *not* the same as setup.exe; far from it. A .package is not 100% self-contained (it doesn’t include the entire Autopackage library and the GUI frontend all the other stuff) and thus not as bloated as setup.exes.
Although Autopackage is inspired by some ideas of InstallShield (scripting), it’s definitely *not* the same as InstallShield and should not be compared with InstallShield.
which happens to include a quick comparison. 😉
i was familiar with redhat and freebsd…it was nice to see what the other’s used, and have a quick example.
good work.
You’re right, actually, however if you execute an Autopackage package without having the Autopackage library or GUI, it connects to the Internet and installs these components automagically. In a way it’s better than InstallShield – though one could conceivable have Autopakcage packages that indeed contain the Autopackage library and GUI, on CDs for example, where bandwidth is not so much of a problem.
It does pose a problem for those who don’t have Internet connectivity, but then again if you can’t connect to the Internet you have more than a package problem…