1

When building packages on a buildbot, I currently have a single buildstep which does

dpkg-buildpackage ...

This works great, but all the output is lumped together into a single step in the waterfall, which makes it hard to see at a glance whether the failure was during configure, during build, or during packaging. So I'd like a finer grained way of building things.

It so happens that I know all the packages I want to build using dh. That means I could have configure, build, test, and package buildsteps, each of which ran one of the following commands:

dh build --until dh_auto_configure
dh build --until dh_auto_build
dh build --until dh_auto_test
dpkg-buildpackage -nc ...

(I use dh to invoke these so it can do the overrides if the package uses any. I don't want buildbot to have to know whether the package in question uses overrides.)

So far, so good. The problem is, dh doesn't want me to use the --until option. It says

"dh: The --until option is deprecated. Use override targets instead."

This makes me sad... sounds like dh doesn't anticipate this use case.

So, now the questions:

Where should such things be discussed?

Does dh actually handle my use case some other way, and I just missed the memo?

Dan Kegel
  • 559
  • 5
  • 11

1 Answers1

0

This probably isn't a great job for dh. It really is just meant to be used from the debian/rules makefile, generally. The --until approach would likely have been pretty problematic for you, even if it wasn't deprecated.

You could, however, split up your build process by taking all the steps that dpkg-buildpackage takes in your own script (the summary at the top of the manpage should tell you everything you need).

But even that won't necessarily let you split up the configure and build parts of the process. debian/rules files are not required to separate those steps or make it simple for the user to do so. Many do, some don't.

My recommendation would be to let dpkg-buildpackage do as much as possible in each phase, still, to avoid messing up something subtle with the build environment, dependency checking, tree prep, fakeroot invocation, or something. Just pass -nc on phases after the first to avoid cleaning up the tree and starting over. dh is smart enough, when phases overlap (like build* and binary*), to skip the parts you've already done.

You could get the right configure/build separation for most packages with something like:

set -e
# check build deps, clean tree, make source debs
dpkg-buildpackage -S -us -uc

if grep '^configure:' debian/rules; then
    debian/rules configure
elif grep '^override_dh_auto_configure:' debian/rules; then
    debian/rules override_dh_auto_configure
elif grep '^%:' debian/rules; then
    dh_auto_configure
else
    : # oh well, it'll get done during the build phase if necessary
fi

# prepare environment, perform build
dpkg-buildpackage -nc -T build

# install stuff into temp dir, tar it up, make the deb file
dpkg-buildpackage -nc -b -us -uc

# remake the changes file, if you care, since right now it only
# includes the binaries
dpkg-genchanges > ../$whatever.changes

At the very least, that should always make correct packages.

the paul
  • 8,972
  • 1
  • 36
  • 53
  • For what it's worth, I have control over all the packages in question, and have been converting them to dh. – Dan Kegel Apr 30 '13 at 19:59
  • (curse stackoverflow's UI :-) For what it's worth, I have control over all the packages in question, and have been converting them to dh. Also, since I'm using this to do things like run Coverity, if I use dpkg-buildpackage, I'll have to pass through one or more environment variables. But I agree that using dpkg-buildpackage (or, better, debuild) is the Way To Build, and anything I hack together has to do what they do. – Dan Kegel Apr 30 '13 at 20:05