Fear and loathing in Las Linux

Disclaimer: I’m a prick. No, really! I complain all the time.

Today, I’m going to complain about Linux, A-GAIN! Actually my gripe isn’t so much with the Linux kernel or community, I’m specifically irritated at Redhat, Fedora, CentOS and any other RPM-based distro that relies on “yum” for installing and updating packages. The yum tool itself comes from Yellow Dog Linux, a distro I’ve never personally used since it’s mainly targeted at PowerPC architectures.

First, some backstory: I’m one of those uber-geeks who likes Gentoo Linux. Gentoo has this very friendly package manager named Portage, which is a simple yet powerful rethinking of BSD-style ports. Like most everything else in Gentoo, it is extremely versatile and configurable in great detail. What I love most about Portage is its no-nonsense approach to version control. With Portage, you can specify which version of any package you want to install, and it will pull in the appropriate dependencies. You can also record custom configurations for any package through the famed USE flags, and the system will happily factor in your preferences when building related software. A seasoned Gentoo admin can finely build their system to perfectly fit his or her needs, all without ever touching any source code.

And then there’s Redhat with their RPM binary packages. They build software based on what the package builder decides, you don’t have to worry about compile-time options because you’re not compiling anything. The converse is that if you want to change anything, you’re pretty much on your own. You’ll need to fetch the source package and build it yourself, or get a source RPM and mess with the SPEC file. So far, it’s not all that bad; in most cases you just run “configure”, then “make” and “make install” and you’re done. The problems start cropping up when you try to update your system. Yum will happily overwrite your custom-built software with a newer version of their generic build, which in most cases will break whatever it is you modified in the first place.

A prime example is Postfix, a mail delivery agent used on a large number of servers. The RPM version of Postfix is rather plain and spartan. It works for many people, but lacks many important options such as MySQL support and Cyrus SASL for secure authentication. While not everyone uses these modules, they are extremely popular in virtual hosting scenarios where one server handles mail for several domains. In other words, the standard build is completely useless for anyone running multiple web sites, as you’ll typically want all of your domains to accept mail. No problem, just Postfix from source with the extra features you need, and this works wonderfully, right until yum decides to update and break your system. Most importantly, there is currently no way to tell Yum to ignore specific packages. This is the one feature I sorely miss from Gentoo’s Portage. With the latter, you can add a line to special file that says “=postfix-2.2.10-1”, indicating the package name and version, and Portage will make sure not to break that specific version. It won’t upgrade it, and won’t mess with its dependencies. It will even downgrade other packages if required, whatever it takes to fulfill your wishes.

The more astute readers might suggest not installing the RPM at all, so that Yum won’t try to upgrade it. Indeed, if you install things manually, Yum won’t even know it exists and will leave it alone. The problem in this particular case is that other packages depend on Postfix, so I can’t uninstall the RPM version or else it will seriously chew out my operating system. It’s a fallacy, as a Linux server can run fine without any mail system, but that’s how the package maintainers scripted it.

So what’s the solution then ? The only way I found was to edit the Postfix SPEC file and give it a ridiculously high version number like 99.9.99, so that Yum won’t find a “newer” version anytime soon. It’s ugly, and it could potentially cause problems with other packages later on, but so far it’s all I could do to keep the package manager at bay. In some ways, Yum is about as annoying as Windows Update, stubbornly messing with things that don’t need to be messed with. Unfortunately for me, my hosting provider wouldn’t install Gentoo on my server, so I’m stuck with Yum.

Both comments and pings are currently closed.

6 Responses to “Fear and loathing in Las Linux”

  1. JD says:

    I completely agree that YUM and RPM SUCKS, but as sad as i am to say this, that is not specifically RH-based distros problem…that’s all binary distros (Debian, Ubuntu, RH, Cent, etc) that have that problem. i do however love and use Debian and Gentoo and i think i’m starting to love Portage. RPM/YUM/RH-based stuff does have a bigger issue though and that issue is “Dependency Hell”…it’s much better than it was before there was yum, but it is still a big issue and a pain in the ass cuz you’ve got to go look for rpms of almost all the dependencies for a package.

  2. Billco says:

    Yep well I agree Yum is a significant improvement over the old chore of manually downloading and installing RPMs one by one, but it’s still the same underlying crap.

    Debian also tends to rub me the wrong way at times, probably because I get impatient with package releases and find myself switching to the unstable branch to get my fix. Like you say, all binary distros end up having to make severe compromises in favor of end-user simplicity.

    Most people end up building at least a few things from source anyway, to fit their particular needs. I think Gentoo balances this quite gracefully by offering pre-built binaries that still play nice with the rest of the system. I started using LiveCDs for installation a few months ago, and while the Gentoo Installer is a bit of a mess, having a working Gentoo system in less than 10 minutes is well worth it. The best part is that the binary packages behave almost exactly the same as source-built apps, with painless upgrades or rebuilds should I feel the need to do so.

    I’ve been tempted to convert my server to Gentoo in-place, but if I screw up (which is a certainty for me) I would end up paying through the nose for the datacenter guys to rebuild it, and of course, they would just reload CentOS on there. CentOS: as if RHEL wasn’t bad enough on its own.

  3. JD says:

    haha…great tagline for CentOS…i think they should use that 😛 Yeah, it’s not worth trying to reinstall the OS on your server by hand simply because if you happen to bork something, it’s REALLY expensive to have the datacenter fix it. As for the Gentoo -bin’s, i don’t really like them because if the big packages on your system are binaries, what’s the point of running Gentoo? i DO like how with them you can have a full system up and running with X and Gnome/KDE in less than 30 minutes, but still, i think part of the Gentoo install is learning and having to deal with things you wouldn’t normally deal with.

  4. Billco says:

    Well see I don’t really mind starting from binary packages because they don’t stick around for long. Gentoo is such an active, frequently updated distro that any binaries eventually get updated along with the rest of the system, as a part of regular maintenance.

    If you really want to rebuild everything, you can still do “emerge world” in a background process once your system is up and running, but I don’t even bother with it anymore. I just run it and within a few weeks, even running the stable trunk, most of the binaries will have been replaced with updates, finely configured and built against my CFLAGS.

  5. JD says:

    For me, Gentoo is not so much about compiling to your CFLAGS as it is about compiling to your USE flags…For example, if i install VLC and i know i’ll never need FLAC support, i can compile it without FLAC support to save HD space and resources when the program’s running. I do love that Gentoo is so bleeding-edge, yet so stable, but i wish there was a easier way to get at hard-masked packages. For me and probably most people as well, it’s too much work to manually edit them out of the package.mask file.

  6. Billco says:

    Wouldn’t that be trivially accomplished with a little shell script ? “awk” seems like the perfect tool for it.