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

Reply via email to