Commit 33bd3c19 authored by Colin Watson's avatar Colin Watson

Add some notes on recommended use of debhelper in d-i, based on my

conversion of most packages to dh(1).

parent 316c9109
......@@ -29,6 +29,8 @@ debian-installer (2009xxxx) UNRELEASED; urgency=low
partman-md respectively.
* Remove mention of autopartkit, removed in r52272.
* Update design.txt to account for base-config's removal (!).
* Add some notes on recommended use of debhelper in d-i, based on my
conversion of most packages to dh(1).
[ Martin Michlmayr ]
* Remove support for the old arm port.
Debhelper standards in d-i
Debhelper is smart enough nowadays that it can build udebs with very little
extra help, so we might as well use its facilities reasonably consistently
rather than having to duplicate lots of code. The dh(1) tool introduced in
debhelper 7.0.0 allows the amount of code in a package's debian/rules to be
more closely related to its complexity: straightforward packages can use a
three-line file that effectively just says "I'm simple, use the default",
and packages with additional complexity in their build process can gradually
override aspects of this.
In general, it is worth attempting to make the build system regular enough
so that we can just use dh(1). The changes required do not usually make the
build system any more complex or non-obvious; normally they just involve
using things like debian/*.install files instead of arguments to dh_install,
although sometimes files need to be moved around to make this work well.
1) Packages that do nothing out of the ordinary in their packaging should
#! /usr/bin/make -f
dh $@
This requires a build-dependency on debhelper (>= 7.0.0).
2) Packages that require installation of scripts with _numbers files, or
use of kernel-wedge, should use:
#! /usr/bin/make -f
dh --with d-i $@
This requires build-dependencies on debhelper (>= 7.0.8), dh-di.
3) Packages that do anything unusual enough to require override targets
should build-depend on debhelper (>= 7.0.50) in addition to the above.
4) Packages with isinstallable files should build-depend on debhelper (>=
7.3.10) in addition to the above.
5) In some cases more than a few override targets are required to use
dh(1), and this results in a rather byzantine rules file. The use of
dh(1) is not required, and if it makes the packaging harder to read
rather than easier then we should just stick to old-style sequences of
dh_* commands.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment