Howto: Build software updates in Ubuntu

Edit: Unfortunately, the images originally included in this post are gone, because of hosting problems in late 2009. My apologies.

Most people don’t realize how easy it can be to update their software in Ubuntu. Perhaps that contributes a little to the culture of entitlement that I occasionally see on the forums, and why it always seems so obvious to me (as someone who regularly uses source-based distros) that someone can update their own system without too much work.

So in the interest of education, here’s a quick-and-dirty primer on how to update a package from the source code. I’ll try to make this as simple as possible so newcomers can also give it a try. Never be afraid to learn something new. (Side note: If you resent the terminal and consider it a threat to Linux’s conquest of the desktop, move along. I know of no way to do this without a terminal, unless you can hard-wire your brain to your PC. Maybe someone has invented a software updater automater GUI thingy, but it would be news to me.)

A preliminary step: A default Ubuntu installation deviates a little from (what seems like) the Linux norm, and leaves out the tools that you use to build fresh software … or they did, last time I checked. Don’t bother debating that point; it’s been that way since at least November 2005, and it’s not likely to change any time soon. And since most Ubuntu CDs include those packages, it doesn’t matter if they’re preinstalled or not. You have them. You just have to tell Ubuntu to put them into place. 😉

sudo aptitude install -y --without-recommends build-essential checkinstall

build-essential is the metapackage for the programs that make other programs. Install that, and you get all the important parts. checkinstall is a nifty little tool that does all the complex packaging, Ubuntu-style, and gives you a portable .deb package when you’re finished. It’s worth using.

So now that the tools are in place, I need some source code. For my example, I’ll build the updated version of Sylpheed — Hardy’s repos are locked at 2.4.8, but I happen to prefer 2.5.0, which has a vertical view option (yeah, I know, it’s a shallow reason, but it’s convenient and easy).

Make a nice isolated directory for building software in your home directory.

mkdir packages

Move the sourcecode there.

mv sylpheed-2.5.0.tar.bz2 ~/packages/

Now uncompress the source package.

tar -xvf sylpheed-2.5.0.tar.bz2

That will make a new directory for the source code, and if the software developer is following the unwritten ettiquette for bundling their source code, you should get a directory with a lot of strangely named files, with subdirectories and a bunch of other good stuff. For this example …

Unfortunately, depending on the software you’re trying to update, that’s going to look different, or perhaps completely rearranged. I’ve seen some software that was so obscurely organized that I really didn’t know where to start. What’re you going to do? 😐

Next step: dependencies. Unfortunately, if you just download any old source package and start compiling it, Ubuntu will have a screaming fit. That’s because Ubuntu packaging omits the source code for the software, and installs only the compiled packages. So the external, dependent sourcecode that this program needs in order to build properly … isn’t on your computer. Yet.

It’s an easy issue to solve.

sudo apt-get build-dep sylpheed

That command will fetch all the necessary parts and pieces to build Sylpheed, in a single swoop. It can be a lot, so be patient. If everything goes right, you shouldn’t get any missing library errors, any obfuscated crashes or mysterious software demands. Of course, it’s always possible that it will do that anyway. In that case, we say it’s a developer error. 😉

(I should note that if you’re interested in changing the CFLAGS or compiler options for your software, now is the time. If you don’t know what I’m talking about, don’t worry about it.)

Now that our dependencies are installed and our compiler tools are in place, we can get started with configuring and building the software. I usually start with this command, from the top directory that was created when we decompressed the source code — in this case, ~/packages/sylpheed-2.5.0/.

./configure --help | less

I do that so I can check which configuration flags are available to me, and in this case, I’m after the --disable-ipv6 flag. I also make a point of adding the --prefix=/usr flag, because default options occasionally put software in locations that are outside my default PATH, which means I have to go hunting for the command to start the program, after I built it! 👿

So for me, this is what my configure command looks like, for Sylpheed 2.5.0.

./configure --prefix=/usr --disable-ipv6

Depending on your package and the options you want, that line will be different.

Now wait. When configure finishes, it might show a list of options that were selected, but that’s not always the case.

Next step: actually build the software.

make

Sort of anticlimactic, wasn’t it? One short command does all the work, and takes up all the time. This is usually the part that takes the longest, and eats the most processor time. (Side note: If you want to know how much time it takes, you can prefix the make command with the time command, and you’ll get a short report on the time it took, after it finishes. It’s good to know for different compiler options, etc.)

Again, depending on the package and the speed of your processor, this can take anywhere from eight minutes for sylpheed or three hours for xulrunner, both at 1Ghz. Annoying, yes. But for those of us who eschew any machine made later than 2001, this is the reality.

When it finally finishes, we have one short step to make a .deb package. Traditionally you install your software with sudo make install, but that tends to make uninstallation a little messy, and it’s nice to have a portable package we can move around. checkinstall does that.

sudo checkinstall

Now you will get a few options that need explanation. Luckily, they’re all trivial, and don’t really interfere with the final product. First …

I usually say yes to this, since a set of docs strikes me as a safe step. You can say no if you want, it won’t break anything. I think. 😉

Next …

Please write a description for the package.
End your description with an empty line or EOF.
>>

Here you can enter the name of the package, or a description. I usually just write, “Sylpheed 2.5.0”, or something to that effect.

Next is a list of options for package maintenance.

I sometimes change the Maintainer’s value to my e-mail address, but you don’t have to. I suppose if you were going to share your update you could do that, but I usually keep my aberrations to myself, and minimize the risk of spreading them. 😉

Press enter for a blank line, and the deed is 99 percent done. The last screen will probably look something like this.

And that’s it. Your package is already installed and a .deb is in the directory waiting for you. And the next time you start Sylpheed, it will look something like this.

For cleanup, if you want, you can move your .deb file out of that directory and delete the entire folder. You can also uninstall all those source code dependencies if you like, since your binary shouldn’t need them to run properly. And if you really are keen on saving space, you can remove build-essential and checkinstall too. Clean up after yourself, your mother always said.

One thing you might be thinking at this point is, “If it’s this easy, what’s the difference between Ubuntu and rolling-release, script-driven source code distros?” And the answer is, not much. In some of those distros, like Arch and Crux for example, the setup options and build commands are all part of the installation script, which just means someone has taken the time to preset some of the values and flags for you. If you use those distros, it’s just cutting back on the time it takes to type all those commands.

But that’s all there is to it. It’s a lot less intimidating than it might look. Of course, every software package is different, but if you’re itching to get the updated version of Critical Mass or something, it’s not a difficult thing to do. Packages closer to the core of Ubuntu are going to be a little more tricky, and complex package bundles can be … complex. 😐 But with a little practice you can learn what needs to be adjusted to get the results you want.