debhelper / autoconf grudge match

Two things recently have made me think about using debhelper to generate a debian/rules that does not need debhelper to build a package.

First, I've been following Helen Faulkner's account of her progress through the new maintainer process, where she was asked to debianize a package without debhelper. I understand the reason to ask a new maintainer that.

But I put myself in the new maintainer's place (suppose I was going through NM again), and I wonder if I would bother to do it by hand, or might instead just run the build once with debhelper in verbose mode and paste the commands it decided to run into the rules file. This could almost be automated, and would almost work. It would be very easy to detect, but I suspect at least the first new NMs to try it to get past that requirement might get by on points for out of the box thinking.

Secondly, Keybuck blogged about wanting to use debhelper in dpkg, but not wanting to add more build-dependencies.

It struck me today that one possible elegant solution to this problem would be to exactly what we already do for Autoconf, Automake and Libtool.

Now before there was debhelper, I used a system close to that for maintaining some (30 or so) packages. I quickly found that updating all my packages each time I made some change to the system was too much work, and I so I threw it away and wrote debhelper. I was happy to find that I could then maintain 90 or so packages instead of the previous 30.

So over the years I've compared doing it the debhelper way, where you build-depend on many small programs with a well-defined, static interface (and a way to change the interface via debhelper compatability levels), with the autoconf way where you essentially compile a build system rarely, but have to do significant work sometimes to update to a new version.

It's hard to compare them exactly because the domains of debhelper and autoconf are so different, but there are similarities like the tools needing to deal with requirements that change outside the domain of the package. For debhelper, think Debian policy changes, and for autoconf think new operating systems or architectures.

And I think we see the same sorts of problems with autoconf and automake in Debian as I saw when I was maintaining my rules file in a similar way. We often have to modify packages just to get a new autoconf feature, such as proper support for an architecture. We sometimes find packages whose existing automakage has fallen out of date and need to spend a lot of effort on making it work with a current version of automake. Oh yeah: and we get nasty enormous diff.gz's sometimes. Debhelper avoids these problems.

My conclusion: Autoconf has some very good reasons to work the way it does, but most of these reasons do not apply to modern unix systems, which already include recent version(s) of autoconf. On these systems the extra build dependency of doing things the debhelper way does not matter, because autoconf is easily available.

That is the main reason why I sometimes use autoconf like debhelper, calling it everytime as part of the package build process. Unfortunatly unlike debhelper it does not have a very well-defined or unchanging interface (and automake is even worse), so sometimes this introduces more work than using autoconf the old fasioned way. At this point it's anyone's guess which use of autoconf in debian results in less work in the long run, and reasonable people (including, I think, Keybuck) think I'm bonkers to use it this way.

Anyway, the all of the above is why I myself have little interest in providing a way for debhelper to be "compiled" into the debian/rules, and why I have even less interest in supporting the general mess that would result if such a tool existed and were used widely in debian. But at the same time I think it's a kind of fun idea and if someone wants to implement it, and use it in their NM application or in the packaging of dpkg, and does a good job while managing to discourage other people from using it unnecessarily, I'd probably accept the patch.

Escpecially since most of the obvious problems I can think of that you'll encounter while doing so are real bugs in debhelper that need to be fixed anyway.