Sometimes You Need to Compile It Yourself

I posted an earlier version of this on the Puppet mailing list recently; it seemed worth expanding here.

An Ideal World

In an ideal world, for each piece of Linux software I use, a very recent version would be “in the box” in the distribution package repositories, for every distro and distro release I use. The package versions would be updated promptly, and backported to the most recent N distro releases. This would be done in such a way as to avoid unexpected breakage, offering a combination of original (as of the distro release), bug-fix-only, and all-updates.

We don’t live in such a world.

The Real World

I’ve found that, with at least Debian, Ubuntu, Red Hat, and Mandrake, typically only the most popular packages are prone to prompt updates for new upstream versions. Backports to not-the-current-distro are even more rare, for various good reasons.

Therefore, when adopting something less widely used, especially if I need the same (current) package version for various distro versions, I’m resigned to having to either package it myself, or find someone “out there” offering updated packages.

Example #1: Puppet

As I write this, the current Puppet version is 0.24.8. It contains a lot of bug fixes and enhancements relative to even the earlier 0.24.x versions. It would probably be only a slight stretch to say that in the Puppet community,  versions before 0.24.x really aren’t recommended for current use at all. Yet the most recent versions offered in-the-box for the last few releases for Debian / Ubuntu are all old enough to be in that category.

Example #2: udpcast

Udpcast is an extremely useful tool, both for cloning systems en masse, and for totally unrelated uses like the one I describe here; yet the version in the very latest Ubuntu is from 2004, and the same is true for Debian.

Example #3: Zabbix

To get good results with Zabbix, it’s necessary to have approximately the same, approximately current versions, on all machines. The versions in various current and past Ubuntu and Debian releases / backports are not even close.

But Please, Use Your Package System

Please, I ask you… and if you work for me on one of my projects, I require of you… do not take any of this to mean you should ever type “sudo make install”.  It’s a nightmare to untangle a system with a mix of packaged and ad hoc compiled code in /usr/bin and friends. Always install using the package system: for a one-off (one machine, ever) install, simply use checkinstall, it takes only an extra minute or two and make it trivial to back the install out later. For a set of production systems. dpkg and RPM are your friends. They won’t bite. Get to know them.

Bar Camp St. Louis, a stealth micro-unconference?

Today I stumbled across the web evidence of Bar Camp St. Louis (Flickr stream, Facebook group) , a software / social networking flavored “unconference”. It occured a few months ago, on Dec. 13th, 2008.  I’m not sure I’d have attended, but I am surprised that went below the radar of any of the various user groups / mailing lists I follow.


Q: How do you know when you’re talking to an excessively enterprisey software vendor?

A: When they require an NDA before they tell you anything about what their product costs.

I’ve been down the enterprise software path; I’ve worked in companies producing it, I’ve worked in companies buying it. I know the drill. I’ve fought the battles to produce quality, polished software in spite of the forces leading toward (ummm….) overly postmodern results.

Be proud of your offerings and your value proposition. Of course we all have situation where a lot of discussions are needed to figure out what a project will cost; but if you have an off the shelf product, it’s just basic block-and-tackle execution to get to a point where you can state a few prices for a few packages as part of your sales presentation.