On Mon, 13 May 2019 at 17:58:47 +0200, Thomas Goirand wrote:
> Now, I have another example, which is quite the opposite one of what you
> gave as example:
>
> https://salsa.debian.org/openstack-team/debian/openstack-debian-images/blob/debian/stein/debian/rules
>
> Why would one want to switch that one to something else? The package,
> basically, consists of a shell script and a man page only.
I would personally *especially* use dh for packages this simple.
It uses dh_testroot, so it probably can't have Rules-Requires-Root: no,
and needs to be built as (fake)root indefinitely - even though a package
this simple can almost certainly be built correctly without fakeroot.
At some point in the past someone, probably you, has had to think about:
- which dh_foo helpers need to be included in the list and which can be
excluded
- which order they go in
which has probably been done correctly, but maybe not - I can't tell. The
fact that they might have been done incorrectly isn't so bad: if they're
wrong it's just a bug, and we can fix bugs. The fact that it would take
thought to work out whether they're correct is more problematic.
At some point in the past someone, probably you, has had to make
this package Policy-compliant when the -arch and -indep targets became
mandatory in order to make Build-Depends-Indep practically useful (perhaps
this package is new enough that you did that as part of its initial
packaging, but either way, someone had to think about it). Adding the
-arch and -indep targets went as slowly as it did because many packages
needed (trivial) per-package changes to enact it.
Part of the value of a dh rules file is that (as Ian Jackson said
elsewhere in this thread) the boilerplate part is trivial, and each
non-boilerplate part (override target) indicates something that is unusual
about this package. A minimal dh rules file immediately tells a reader
"this is a completely ordinary build process" and that's a valuable
thing to convey to a reader.
smcv
