[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: debhelper 7 conversions

Inspired by Joey's talk at DebConf, I've been working on converting all
of d-i to debhelper 7. Obviously this can be done just by bumping the
compat version and testing that the result is sane, but where it makes
sense I'm trying to go the whole way and use dh(1).

While this sometimes involves some non-trivial changes to the packaging
(for instance, sometimes I needed to move things from debian/rules to
Makefile), I think that on the whole it makes the packaging much simpler
and less full of (IME often wrong) cargo-culting. Joey said at DebConf
that the idea was that if you saw a package with nothing more than 'dh
$@' then you knew it was a straightforward package with nothing weird
going on, and each addition to that represented some kind of deviation
from normality. I really like this model. CDBS tried something similar
and I hated it because it was incredibly painful to figure out how to
override its behaviour, but debhelper's documentation is excellent and
it's really easy to start with 'man dh' and follow references to see how
to override the behaviour of individual commands when it's necessary. In
a few cases the necessary overrides get out of hand and it works out to
be most comprehensible to continue using ordinary hand-written sequences
of dh_* commands, but there seem to be relatively few of these. At this
point I've gone through enough of it to be able to say with confidence
that the bulk of our packaging is entirely formulaic.

I've committed a few simple cases already, but I thought I'd best check
with the list before going further and committing more from the pile of
stuff I have on my laptop. I'm not sure that individual patch review
would be all that interesting as it doesn't actually change the
behaviour of d-i at all, but I'm more interested in opinions on the
conversion in general.

In particular, some packages do genuinely get complicated, and need
override_* rules, which require debhelper 7.0.50 which isn't in stable
(although there's a backport in lenny-backports). Would this cause
anyone any serious inconvenience, or should we just go ahead and use the
new tools? IIRC stable-and-a-half efforts mostly tend to use the
installer from testing, which leaves things like Kenshi Muto's
backports; at the moment I'm operating on the assumption that if
somebody is doing something fairly heroic like backporting d-i,
installing a backported debhelper probably won't be much of an
imposition. Please shout if this is a bad assumption.

I was planning to leave out the *-support packages, as well as
live-installer which is currently using CDBS.

Some packages present particularly interesting challenges, in that they
require essentially formulaic overrides that would be best encapsulated
by new debhelper commands. partman and the kernel udebs fall into this
category. For these, I'm writing a dh-d-i debhelper addon (originally
dh-partman, but Joey suggested renaming it so that it can cover other
things we might want to do now or in future). Currently I'm planning for
it to contain a utility to install directories with _numbers files, as
used in partman and rescue, and a utility to replace
/usr/share/kernel-wedge/generic-rules. Eventually this means that we
should be able to converge on 'dh --with d-i $@' in rules files.

Any comments?


Colin Watson                                       [cjwatson@debian.org]

Reply to: