Jari Aalto <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
