Why I'm unhappy with how Debian builds from source packages right now
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.
|
|