Re: debian/rules::dh_* comments as rejection criteria
Jari Aalto <jari.aalto@cante.net> writes:
> 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 is what the debhelper documentation is for, and as an advantage gets
one the current list of calls and the current order as opposed to whatever
the maintainer happened to grab when they built the package.
I agree with the ftp-master recommendation here. In the packages that
I've looked at, the commented-out dh_* calls are generally unmaintained,
meaning that old cruft is left around that, if uncommented, would result
in running deprecated debhelper commands or doing things that are no
longer the best way of handling package building. I would much rather see
people go look at the debhelper samples when they realize they need a new
helper script than keep around a commented snapshot of whatever the state
of the world was when they first ran dh-make and which they haven't
changed since.
> This recommendation looks like from 70's where optimizing C-code was the
> status quo and not the readablity, maintainebility.
The rule is not about optimization. Removing unmaintained comments that
are of questionable relevance to the package increases maintainability.
> Having dh_* calls there help possible follower maintainer (if package is
> orpaned), who may not be as skilled as the originala maintainer.
People adopting packages need to understand the build system that the
package uses or need to repackage the package using a different build
system. They need to at least have sufficient understanding of Debian to
be able to find the debhelper documentation themselves.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: