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.


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.


8 thoughts on “Howto: Build software updates in Ubuntu

  1. Aren Olson

    Checkinstall is actually kinda a dirty hack. while it works fine for many cases, it’s not completely compliant and can in fact mess up apt in some circumstances.It is MUCH better to actually generate the full debian packaging. If you’re just grabbing a new version of something in the repos already, this is often as simple as getting the old deb source, copying the debian folder into the new source, updating the changelog and running dpkg-buildpackage -rfakeroot. There is an excellent guide to making debian-standard packages on the ubuntu forums here:

  2. johnraff

    For beginners (like me) one option is to edit checkinstall’s config file /etc/checkinstallrc so as to make the deb only, not install it.
    The line’s at the end:

    # Install the package or just create it?

    Then you can run checkinstall without sudo, the deb file will belong to you, not root, so you can delete or move it easily, and you’ll only need sudo when you finally install the software.

    This way you can look at checkinstall’s output while it’s making the deb, and if there’s anything weird going on you needn’t install the deb, and your system’s untouched.

  3. K.Mandla Post author

    Thanks, those are both good tips. I’d seen the tutorial thread about proper Debian packaging a long time ago, but for something I was only making for my own use, I always found checkinstall to be quicker and easier.

  4. johnraff

    I forgot to mention dependencies.
    If you go with the default settings the deb file that Checkinstall makes will have no record of dependencies, so if you update an application that was in the repositories from the source code, any dependencies that were brought in for the original app will now look like orphans. If you then do some kind of auto-clean, with eg deborphan, your new version of the app will be broken.

    You can use Synaptic (or command-line methods) to remove the “automatically installed” marking of those dependencies so they’ll be safe, but now if you ever uninstall the application you updated the dependencies won’t be automatically removed.

    Just something to be aware of…

    btw this failure to allow entry of dependencies in option “[]10 – requires” may be a Checkinstall bug that gets fixed in the newest version.
    It’s just conceivable that the version in the Intrepid repositories fixes this:

  5. johnraff

    (This is a second attempt to post – are posts with URLs in them blocked? Anyway…)
    I forgot to mention dependencies.

    Checkinstall, at least the version I have, doesn’t let you enter anything in the “10 – Rquires [ ]” option, and when the deb’s installed APT doesn’t see the package as having any dependencies, so any libraries or other programs you installed as dependencies of that package will appear to be orphans and if you run any kind of auto-clean, with deborphan for example, they’ll be removed, breaking your package. You can use Synaptic, Aptitude etc to remove the “automatically installed” tag on them and keep them safe, but now if you ever uninstall the package the dependencies won’t be automatically removed.

    Just something to keep in mind…

    Scouring the web I found some Debian and Launchpad threads suggesting this inability to set dependencies was a Checkinstall bug which might have been fixed in version 1.6.1-8 (or even in the Intrepid repository) but my last attempt to post failed so in case the urls were the cause here is the end of one:
    please put https colon slash slash on the front…

    Intrepid’s 1.6.1-7 brings in a new dependency on dpkg-dev which suggests it might be getting a bit deeper into the debian system.

  6. Pingback: Rebuilding Dillo 0.8.6-i18n-misc « Motho ke motho ka botho

  7. Pingback: That chortling noise « Motho ke motho ka botho

  8. Pingback: A little cheese, for your whine « Motho ke motho ka botho

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s