debian/rules::dh_* comments as rejection criteria (Was: Re: A list of common gotchas in Debian packaging)

[Jari Aalto <jari.aalto@cante.net>]

Russ Allbery <rra@debian.org> writes:

> Simon Richter <sjr@debian.org> writes:
>
>> I do that all the time. It is much easier to see that a program is not
>> being run if it is explicitly commented out rather than just "not
>> there", as Makefiles tend to be executed in interesting nonlinear ways,
>> and it doesn't really hurt either. Even the slowest of our buildds can
>> skip over these lines in less than a second, while if I screw up with
>> these lines I'm wasting a lot more autobuilder time, archive bandwidth
>> etc.[1]
>
> One can certainly argue both sides of this, but on this point in
> particular, ftp-masters actually made a ruling and asked people to remove
> the commented-out lines.
>
> See <http://ftp-master.debian.org/REJECT-FAQ.html> down near the bottom
> near debian/rules.

This is bad, such micromanagement for few commented lines should not
warrant rejection criteria by the ftp masters. The dh_* calls are
there for later upgrade of the package and retaining the order of the
items is not the same as this pages' suggestion:

        "Edit them, test your package and then delete the whole bunch
        of commands that are commented out, make it hard to read and
        do not help. If you later need anything: Type dh_[TAB][TAB] to
        see whats available."

Who can remember the correct order of dh_* calls later on? 

This recommendation looks like from 70's where optimizing C-code was
the status quo and not the readablity, maintainebility.

Having dh_* calls there help possible follower maintainer (if package
is orpaned), who may not be as skilled as the originala maintainer.

Please lift of the sentences from REJECT-FAQ.html if there are currently
included in rejection criterias. 

Jari