Why I'm unhappy with how Debian builds from source packages right now

October 26, 2016

A few years ago, I wrote about a problem with how Debian builds from source packages, namely that it builds your binary packages in the source package working area and this can lead to contamination of your source package working area. Fast-forward to today:

@thatcks: Current status: really hating the Debian approach to building packages because it commingling source & build areas has blown up in my face.

@thatcks: I think I'm going to have to extract my change, nuke the entire package area, and start over completely from scratch, testing included.

I'd been making a change to a quilt-based Ubuntu source package. It was a simple change, I had it in a quilt patch since we've done this drill before, and I'd built and tested the updated binary packages. As one of our pre-deployment steps, an obvious thing to do was build a source package too as a nice encapsulated artifact of our changes.


$ debuild -S -us -uc
[... natter natter ...]
dpkg-source: info: local changes detected, the modified files are:
dpkg-source: error: aborting due to unexpected upstream changes, see [...]

There is only one problem: I hadn't changed configure. At all.

The upstream tarball of this package ships a configure.ac as well as the straight configure. My best guess is that building the package from source the way Ubuntu does it re-runs autoconf, and the autoconf-generated configure is different from the upstream configure in minor ways (the actual diffs are small but plausible for this). This means that after a single build, your source package working area is contaminated unless you carefully save or re-extract the original configure in order to put it back at the start of any rebuild.

(Indeed I just did a test 'debuild -b -us -uc' on yet another scratch copy of the source, and it seems to have run autoconf.)

I assume that the people who maintain this Ubuntu package don't notice this because the normal Debian source package is not how they actually work with it. Instead I suspect that they have it in git, build it with automated builders that always start clean from a source package, and so on. In other words, they have a different industrial production system and the source package is a lie.

It's difficult for me to find words to express how this makes me feel. Angry is certainly part of it, not simply for what this means for us making changes to the package but also for what it means about how much the package maintainers and Ubuntu in general care about the 'standard' way of building packages. At the best, practices have shifted once again without anyone making it official and clear; at the worst, outside people like me are simply second class citizens when it comes to package work.

(This is of course par for the course for Ubuntu, where Canonical has been extending various digits in people's directions for some time, but I don't have to like it.)

I have no idea what this means for how we want to maintain our local changes here. I have at best vague theories. Probably I'm going to have to try to find unofficial information online about how other people do it.

(This is definitely going to slow down our work with the package, too, and I'll leave things at that rather than going off at length here.)

PS: One thing that this means is that the Ubuntu package build process lacks consistency checks to detect this sort of thing. Given an aphorism, I expect that there are plenty of Ubuntu source packages that have this problem.

Sidebar: Some actual build-time output

 debian/rules build
# <pkg>
[runs configure]

And debian/rules has a 'config-stamp: configure' section that does the dh_testdir stuff et al. The earlier output is from the 'clean:' section of debian/rules for this package. So I believe I have the root cause identified.

Whoever thought that re-running autoconf was a good idea, well, I have no words.

Comments on this page:

Try removing the modified files in your clean rule.

By cks at 2016-10-27 10:39:47:

There's two problems with removing the modified file somewhere in debian/rules. The first is that it's shipped as part of the pristine source, so I assume that removing it would provoke its own set of complaints from dpkg-source. The second is that I don't know anything about manipulating debian/rules; we're making a minimal source change to a package, and I'd rather not start patching debian/rules as well and so on.

By zdw at 2016-10-27 20:00:35:

Since I also needed a CI solution for other tasks and all the code we're building is stored in a git repo, I started using this:


Which builds in a clean environment, with defined prereqs every time, and does other automation like auto-adding it to an apt repo.

This was discussed on the debian-devel mailing list in 2013. See https://lists.debian.org/debian-devel/2011/03/msg00657.html and replies.

Basically, the debate turned out to be about what to do with autotools generated files like configure that upstream ships in the tarball (which is quite common). People discussed advantages and disadvantages of leaving them be, or stripping them before assembling the source package, forcing re-generation in every build. It was an interesting discussion to follow, although it doesn't seem like any conclusion or agreement was reached.

This is what https://wiki.debian.org/ReproducibleBuilds is trying to solve (and, it appears, they have wide support.)

Whether or not Ubuntu gets there is a different story.

By Ben Hutchings at 2016-10-28 15:04:26:

Deleting the generated files won't upset dpkg-source that much; it will warn but not fail.

As Anton noted, this is a real problem in Debian's packages and not specific to Ubuntu. It's something that gets some automatic testing and is sometimes fixed but often regresses.

Having been burnt by this many times while working with unfamiliar source packages, I can suggest doing either:

  • Check the unpacked source package into git, so you can use git reset --hard and git clean -d -f -x to clean up generated files
  • Build the source package with dpkg-buildpackage -S and then use pbuilder or sbuild to build the binary packages (but of course those take some work to set up)
Written on 26 October 2016.
« What I'm doing to use a Yubikey in Fedora 24's Cinnamon desktop environment
How I set up a DHCP client for my backup Internet connection »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Oct 26 23:19:47 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.