debhelper.txt 1.92 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
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
    use:

	#! /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.