Petreley on apt-get vs. RPM
cagrin wrote to us with a recent Nick Petreley feature on LinuxWorld. In this feature, he writes about one of my most favorite parts about Linux: Debian and apt-get. He's advocating that Debian become the standard for Linux, as RPM doesn't cut the mustard compared to apt-get. Now, granted, I've been able to blow up my machine before with reckless apt-get dist-upgrade -- but that's running unstable, and my own fault. Apt-get rocks.
If rpm could be configured to look around, in the standard places, for a particular library it would greatly simplify my life as a sysadmin. For example, openssl is stuffed into /usr/local/ssl. In recent RH rpm updates ssl is required but since I hadn't installed the openssl rpm it wouldn't install those packages until I take the time to --force it or --nodeps or whatever is necessary to get it to go.
Many packages I install manually because of the complexity of getting many installs working properly. The Apache-php-mod_ssl-openssl-imapd combination is one good example. I like to be able to update all of these packages as soon as possible if a serious problem occurs with any one of them. This is also the reason that I don't bother with kernel rpm updates since I normally am 2 minor versions ahead of redhat anyway.
These dependancies should be extended from the rpm level to library level. If an rpm for a given library is not found then rpm should go looking for the default location of the library itself before coming back with an error. I'm not even sure that it should be an error, perhaps a very strongly worded WARNING would be better, or at least a configuration to do this by default. Hmmm, I wonder if I'm missing something ...
:wq
Surely apt-get is an app that sits on top of dpkg - rpm is not an app for getting updates so you can't compare the two. You should be comparing apt-get with red carpet or something equivalent for a true comparison...
--- If something doesn't feel right, you're probably not feeling the right thing.
AFAIK,
The conventional wisdom is that BSD ports and Debian apt are the two most powerful and versatile upgrading systems around. Apt downloads packages from central Debian servers and takes care of every detail, including dependencies, in installing them on your system. A port downloads the source from wherever it is (the makefile usually specifies up to 50+ servers to try, depending on the port), builds it if necessary, and installs it, taking care of every detail, including dependencies (run and build) and complile-time options.
To editorialize, either one is a good way to run a clean, stress-free system. Note that although it would be just as easy to download a precompiled package from a central server and install it on BSD (pkg commands with/without make install), the "cultural" emphasis in the BSD world (correct me if I'm wrong) is to compile from source. Obviously this is a more resource-intensive model (and one ends up with a number of versions of make), but BSDers like it (after all, it puts the "source" in open source). And there are those compile-time options.
Although, there is room for improvement in both apt and ports, both seem to have the right idea as to what constitutes a good way to upgrade a system. Thus both should continue to be excellent options.
Note: for downloading/tracking a large source tree, CVSup actually is perfect, with no room for improvement :-)
"Frederick, is God dead?" --Sojourner Truth
A recent security recent hole in Mandrake required I download about 40Mb of GLIBC RPMs! Why??? The fix itself was probably a few changed lines in the source code so why not distribute it as a binary patch? The alternative for modem users is a 3 hour download, something only masochists will bother doing.
rr
Quidquid latine dictum sit, altum videtur.