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.

So:

$ debuild -S -us -uc
[... natter natter ...]
dpkg-source: info: local changes detected, the modified files are:
  <package>-<ver>/configure
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

[...]
dh_autotools-dev_restoreconfig
debconf-updatepo
dh_clean
 debian/rules build
dh_testdir
dh_autotools-dev_updateconfig
autoconf
# <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.

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, Add Comment.
Search:
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.