Matt Campbell's Blog

Rambling on a Sunday afternoon
Today's my day off from working on FreedomBox. Mike Calvo (my boss) is quite happy with the work I've been doing on the FreedomBox instant messenger. So far it only support MSN Messenger; I'll work on AIM tomorrow. The UI is certainly rough around the edges, but it's functional enough that Mike and I have both used it for real IM conversations. As for AIM, I haven't yet decided which protocol to use, OSCAR or TOC. Clients for both are included with Twisted (http://www.twistedmatrix.com/), but the TOC client might be easier to work with since there's more sample code for it. Anyway, I'll make that decision tomorrow.

David Csercsics and I have been working on a new GNU/Linux distribution. Our goal is to provide a bloat-free base system built from pristine sources, without applying lots of patches to critical packages as other distros tend to do. I had chosen RPM as a packaging format, and David agreed to try it, because we thought its dependency system was cool, and I like the RPM spec file format (except when you use lots of macros). We originally chose the name "Vanilla GNU/Linux" for the system; I'm not sure if I want to stick with that name.

David wrote RPM spec files for most of the packages in the Linux From Scratch book, and he successfully built binary packages. However, now he's running into some problems when trying to install the packages into an alternative root directory. Most importantly, when he installs the glibc package, rpm hangs, unless he includes the --noscripts option. He's also found that if you give RPM a bunch of packages to install, it doesn't figure out the correct order in which they need to be installed to satisfy dependencies. I thought I read something about that problem being addressed in RPM 3.0, but I guess not.

I'm also not totally comfortable with RPM's use of a binary database to store important information about the installed packages on the system. I've read arguments against this approach, saying that such a database could be corrupted as the Windows registery is sometimes corrupted, thus rendering the package manager basically unusable. A directory (or directory tree) of text files would be a more reliable solution, I think. That's what dpkg (Debian's package manager) uses. dpkg is slow on my old 266-MHz box, but I think that's because /var/lib/dpkg/status has a record for each *available* package, instead of just the currently installed ones. At least, that's how it is if dselect is used at all. Maybe if I used apt exclusively, that wouldn't be as much of a problem.
So why did I choose RPM instead of dpkg? Well, to be honest, aesthetics have a lot to do with it. Just looking at a package file names, I like "glibc-2.3.2-1.i386.rpm" better than "libc6_2.3.2-1_i386.deb". First, RPM packagers (particularly those who work for Red Hat) tend to preserve the upstream package names more than Debian packagers do, especially when it comes to libraries. Another example that comes to mind is that Debian's OpenSSH package is simply called "ssh". Actually, that's not just aesthetics; I cosider that misleading. I also like dash better than underscore as a separator between the name and the version number; the dash is more traditional and to be honest, I just like the way it looks. Same with period vs. underscore as the separator between version and architecutre name.

But I have deeper issues with dpkg. First, when installing and upgrading packages, dpkg sometimes assumes that someone is watching the installation process and can provide input from time to time, for example on whether to replace a config file or leave it alone. Debconf has helped in this area, but still this assumption on dpkg's part disqualified Debian as a base system for the FreedomBox Surfboard. Yeah, we could build a system from scratch using dpkg, where the preinst and postinst scripts would never take input from the user. But sometimes I think dpkg itself requires user input during an upgrade.

The next issue is how to express dependencies on shared libraries and binaries. With RPM, packages can depend on "libc.so.6", "perl(Time::HiRes)", "/bin/sh", and so on. I like this, because it means (in theory) that it doesn't matter which Bourne-compatible shell you use, as long as all the shell scripts in the base system avoid bashisms. With shared libraries, there's usually only one implementation of a particular library, but this form of expresing the dependency means that it doesn't matter what the package name is. I'm not sure what Debian's rationale is for using package names like "libc6" and "zlib1g" for package libraries, but maybe it has to do with the fact that dpkg doesn't use "libc.so.6" and the like to express dependencies on such libraries. So that's an RPM feature that I really like.

Then there's the package build system. All you have to do is compare (say) the libogg spec file with the debian/rules and debian/control files in the libogg package to see why I like the RPM build system better. RPM spec files can be quite simple, and all the info needed to build a simple package (or in some cases a group of binary packages) can be there in one file. Debian doesn't have this. Also, RPM has a standard way of keeping the pristine source, the patches, and the package build specification separate. With Debian, a source package consists of an upstream source tarball (which is sometimes a tarball created by the Debian maintainer which contains the real upstream tarball), a diff.gz file which contains all the Debian patches and build files, and a .dsc file which I guess has metadata about the source package that dpkg-source uses when unpacking the source package. RPM might have been better off storing the upstream source, patches, and spec file in a tar.gz file instead of a src.rpm file (which you have to have rpm to unpack), but on the whole, I like RPM better when it comes to building packages.

Some people who know me may know that I used to be a Debian fan. The ACB and FreedomBox servers run Debian because I suggested it. But that's not because I particularly like dpkg itself. I do like APT as a tool for installing and upgrading software; as long as a sysadmin is there to answer the occasional question, it's a pretty good tool. Red Hat (um, I mean Fedora) now has something like APT, called yum (YellowDog Updater Modified). But that wasn't there when I recommended Debian to the ACB, and I didn't yet know about yum when we set up the current FreedomBox servers at ServerBeach.com. Also, though I think RPM is cool in some ways, I don't like Red Hat (now Fedora) as a distribution. It's bloated, recent versions use NPTL (which doesn't work well with some apps), Fedora takes an unusually long time to boot even on my powerhouse desktop... I just don't like it.

So I'm not really happy with either of the "big two" packaging systems. What about the alternatives? Well, the Slackware packaging system uses a directory of text files to store info about installed packages, and that's cool, but there's no dependency checking at all, and Slackware allows multiple packages to have the same files, which could get messy. Also, package building in Slackware seems pretty ad-hoc to me. Some SlackBuild scripts do the whole procedure from unpacking the source tarball to creating the .tgz file(s), while others simply install the package on the build machine. So as far as I'm concerned, Slackware's package system is out of the question.

What about Gentoo and Portage? Well, Gentoo as a distribution is definitely too bleeding-edge. The other day Kenny Hitt posted a message to the linux-port@freedombox.info mailing list about trouble he had getting FB to run on Gentoo. But FreedomBox runs fine on Debian, Slackware, Linux From Scratch, and even Fedora. As for Portage, it's a source-based package system, which requires (or at least encourages) you to build packages from source, configured just the way you want them with your optimizations, etc. Frankly, I think that's only acceptable for geeks who have no life.

So what should be done? I don't have time to address this problem at the moment, but I wonder if it would be best to improve RPM, improve dpkg, look for an alternative, or write one from scratch? I know it's bad to re-invent the wheel, but I haven't found a GNU/Linux package manager that I can honestly say I'm satisfied with.

Well, that's enough rambling for now. I don't post to LiveJournal often, at least not yet, but since I don't really have anything to get done today, I figured I'd take this time to just write what I've been thinking about, particularly regarding GNU/Linux package management.

Hopefully I'll post again sometime soon.

Current Music: The Nobodys - Hollow (the album, nost just the song)

Advertisement