In my attempt to convert e2fsprfogs's debian/rules to use dh, I'm
running into yet another frustration with dh, which is that it insists
on running the configure script twice.
The problem is that dh is trying to use build-arch and build-indep:
% dh build --no-act
debian/rules build-arch
debian/rules build-indep
And build-arch and build-indep both want to run configure:
% dh build-arch --no-act
dh_testdir -a
dh_update_autotools_config -a
debian/rules override_dh_auto_configure
debian/rules override_dh_auto_build
create-stamp debian/debhelper-build-stamp
% dh build-indep --no-act
dh_testdir -i
dh_update_autotools_config -i
debian/rules override_dh_auto_configure
debian/rules override_dh_auto_build
create-stamp debian/debhelper-build-stamp
This seems.... amazingly non-optimal.
I tried to see how other packages work around this misfeature, and I
see that openssh just hacks things to make the second
dh_auto_configure a no-op:
override_dh_auto_configure-arch:
dh_auto_configure -Bdebian/build-deb -- $(confflags)
ifeq ($(filter noudeb,$(DEB_BUILD_PROFILES)),)
dh_auto_configure -Bdebian/build-udeb -- $(confflags_udeb)
# Avoid libnsl linkage. Ugh.
perl -pi -e 's/ +-lnsl//' debian/build-udeb/config.status
cd debian/build-udeb && ./config.status
endif
override_dh_auto_configure-indep:
RLY?
That seems like an amazing hack. Is there no other way to work around
what appears to be massive mis-design in dh?
If the goal is to make moving to dh a mandate, and working on Debian
to be fun, we desperately need better documentation on how to use dh
for real-world packages, and not just simple, trivial packages.... :-(
- Ted
