Chris's Wiki :: blog/linux/DebianSourcePackageProblemsII

Another problem with how Debian builds from source packages

August 21, 2012

When I wrote my first entry on this I didn't realize one more significant problem with the way Debian builds packages from source (because I hadn't run into it my own package building). This is that Debian builds binary packages in the source package working area.

It's easy to see how this came about. Since the unpacked, working form of a Debian source package is a directory tree with the source code and some extra information, doing an in-place build when compiling and building binary packages is both trivial and the obvious and simple approach. And usually everything works fine.

The problem is that this has the same failure mode as patching your source code in place during the build. You are crucially dependent on the software's build and cleanup processes actually cleaning everything up, both routinely and especially when things go wrong. If things do not completely clean up, always, then your working area for the actual package gets contaminated with artifacts of the build process, artifacts which you will have to disentangle from your own changes to the package and then remove by hand. You're also dependent on the build process not modifying anything in the original source tree; if it makes modifications itself, you're again going to have to disentangle and revert things by hand.

But wait, we're not done. There's another worry: reproduceable builds. Suppose that you are repeatedly building versions of the package (for example, you're testing a change). How sure are you that the build process has not contaminated the source tree such that your repeated rebuilds are producing a different result than what you'd get if you started from a just-unpacked tree? After all, the same source tree is being reused over and over again for each rebuild.

(In theory the package's cleanup process is not supposed to leave anything behind. Practice may be different from theory.)

Contrast this to the situation with a separate build tree. When you use a separate build tree, you can clean it up simply by deleting it all and you can always start from a known state by recreating it every time you build the package. The software being built can do whatever bizarre things it wants to inside its source tree (including patching its source code on the fly) and it won't contaminate anything else or get confused with your changes.

(The downside to a separate build tree is that you have to set it up every time. This slows down building packages as you copy and/or extract a potentially large source tree into your new build tree.)

Comments on this page:

From 134.173.34.85 at 2012-08-21 17:22:40:

These days a lot of people are checking things into version control and using tools to build the packages, and those tools (e.g., svn-buildpackage) do a separate checkout of the code into a build area and do the build there. And, of course, you could always do a fresh unpack of the source package before building, which would help you with additional debris (the tar file included is the upstream tar file).

The RPM way does builds in a separate directory, so it's easier to keep things from getting cluttered up, but it also does a whole bunch of magic in terms of setting up the environment that can often make debugging a failed build require a great deal of poking around and setting environment variables to try to replicate the problem.

Then there's the *BSD ports system, and its various implementations.

As with many things, it seems like package building sucks in general, with any particular system having some advantages and some disadvantages over the others.

Claire.

By cks at 2012-08-22 01:34:22:

Repeatedly rebuilding an unchanged package is relatively easy. The problem comes when you are modifying a package and rebuilding; then your source tree has your modifications and you can't casually toss it and re-extract it.

(This is what happened to me.)

The annoying thing is that this would be easy for Debian to fix, even as a build option. All you would have to do is add a feature to debuild or dpkg-buildpackage so it would copy the entire source tree to your designated temporary build area, run all the build commands, and copy any output (.debs, source packages, etc) back.

(I suppose you could even do this as a hack on top of debuild with a little frontend script or the like.)

From 213.47.133.111 at 2012-08-23 10:04:37:

You realize that this is what pbuilder solves?

By cks at 2012-08-24 11:35:36:

Pbuilder is clearly useful but I think it's solving a somewhat different problem than I want to solve. Using an entire separate system image is a bit heavyweight (and requires special privileges) when all I want to do is compile packages in a scratch directory tree so that they don't muck up my work tree.

From 89.70.184.230 at 2012-09-09 19:13:55:

Repeatedly rebuilding an unchanged package is relatively easy. The problem comes when you are modifying a package and rebuilding; then your source tree has your modifications and you can't casually toss it and re-extract it.

Well, you can. Just use ephemeral git repository for working form of a package. I know that this is a mitigation of a problem, not a solution, but on the other hand, I happen to hack some code every now and then and this approach (unpacked source, git repository and modifying this source in-place) helps me quite a lot. After I have finished my work, I can easily produce diff and include it in debian/patches. Doing the same for RPMs turns out to be quite difficult.

Anyway, I use git for every and all hacking that I'm doing. This is great to have a change history, either when fixing some web application (upgrades won't kill your local changes) or when reconfiguring Apache/MTA/Bacula/Nagios/WhatEver(tm). Using a git repo is a no-brainer for me.

Written on 21 August 2012.

«	Sysadmins hate updates (more or less)

My view on the understandability of language idioms