Slashdot Mirror


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.

5 of 240 comments (clear)

  1. Dependencies by mrfiddlehead · · Score: 4
    The biggest problem I've had with rpm, IMNSHO, is its inability to deal with dependancies of non-rpm packages on the system. I don't mind having to go root around for my rpm updates, in fact I prefer this so these benefits for apt-get aren't of great concern to me.

    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
  2. Not the same thing by Skruffy · · Score: 4

    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.
  3. Re:BSD ports vs. Debian apt-get by skbenolkin · · Score: 4

    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
  4. Binary patches would be nice by DrXym · · Score: 5
    I would be happy if the vendors would start shipping certain updates as binary patches.

    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.

  5. The _REAL_ difference by CarrotLord · · Score: 5
    is not actually the fact that apt-get is not comparable to RPM, but the fact that Debian has a strict policy on package dependencies. The main difficulty with porting apt-get to RPM (and in fact, the main difficulty with any automated system for RPM) is that there are no standards about how to make your rpms. You just do it whatever way you wnat. RedHat themselves don't conform to the LSB filesystem standard, which doesn't help. IMHO, any packaging system must have complete and strict dependencies, and policies on these so that a package is not valid unless it's correct and pretty damned complete, and it must comply with the LSB as much as practicable. Debian does this, no RPM distros do. Hence, Debian is easier to maintain.

    rr

    --
    Quidquid latine dictum sit, altum videtur.