The Problem With Packages

For the most part, packaged software is a big help. For one, packages make installing software rather easy, even for new users. They help save space, as you won’t have space tied up by source code you don’t need. They’re also fast, requiring no compile time. However, they do have their drawbacks.

Binaries aren’t always going to be optimized for your system, for starters. Consider Slackware vs. Arch: while the latter is based on the former, Slackware compiles their packages for the i486 architecture for greater compatibility, while Arch compiles against i686. If you’re running an RPM-based distro you could hit RMPFind, as there are a plethora of packages built against several different architectures and distros. However, this same plethora can be confusing, especially for a newbie.

Next is the delay in updates. When a critical vulnerability is announced, you typically have to wait for your vendor to put out an upgraded package, or you have to wait for it to show up on sites like RMPFind. This isn’t a tremendous problem if you’re running Red Hat and the package you need to update is part of the distro, but if you’re running an unsupported package like an MPlayer, you’re on your own until someone builds a package for you.

A bigger issue is having to use the package as is. If the package builder doesn’t compile in features you want or need, you’re out of luck. Using the MPlayer example, the package builder may not have built in all of the audio and video capabilities you may need, or may not have enabled some codecs. More recently, I had a problem with KMail; while I received it as part of Slackware’s KDE 3.4 package, I can’t send authenticated mail through my SMTP server at work because the related component wasn’t built into the package. I didn’t have this problem with a previous version.

A similar problem occurs in vendor-supported distros. Red Hat is notorious for patching and re-issuing packages rather than updating them. They do this to prevent introducing bugs in production environments, which makes sense. But this also means you won’t get the latest-and-greatest features. I ran into this with a Red Hat kernel back in the day, one which didn’t support my Zaurus.

As a result of the latter, you may end up building from source. This is fine for the most part, but now you deal with a related problem of mixing packages with sources. Sometimes, source code expects certain dependencies to be found in a particular place. But, because a package builder may keep a dependent in a non-standard location, the source code can’t find the dependent and craps out.

Welcome to dependency heck.

Gentoo tries to get around a lot of this with their Portage system. My understanding is a script contains all of the configuration settings you’ll need, and then the system downloads and compiles the source code per those instructions. You still have to deal with long compile times, but you can get into the scripts to adjust what you need to make sure you have the features you want.

Personally, I rather enjoy working with FreeBSD’s Ports system. It still has its drawbacks, but you can install or upgrade a package with two or three commands. The source is downloaded and compiled right there on your system, and some of the ports/packages will pop up a menu asking if you want to include certain features or options. Still others, such as the PHP port, include the extra options or modules as a kind of bogus port which simply alters the config file of the core port.

The point is, software installation on Linux is a messy animal. It’s also one of the toughest things to explain to a newbie. Those coming from the Windows world are used to downloading a single file to double-click and then start playing, not downloading something and running it through a package manager (or, failing that, wrestling with source code).

So what’s the solution? It’s hard to say. Getting everyone to put their packages and libraries in the same location would be helpful, but that’s probably not going to happen. I do know what I’d like to see, though.

Given the strides Linux has been taking toward the desktop, I don’t think it would be unreasonable to hope for a better set of tools to manage sources. The make xconfig option for building a kernel config file is probably close to what I’m thinking. It wouldn’t be practical to completely reinvent the wheel by changing the way config and makefiles are written, but why not a front end to them? A GUI that will present the various options, maybe with a “default” config set up by the developer? Then, like FreeBSD and Gentoo, it drags down the files it needs, compiles, and installs. As long as developers are consistent with the structure of their config and make files (and most are), this shouldn’t be a terribly difficult project.

Now if only I knew the first thing about programming and development…