On 20050517T120701-0400, Joey Hess wrote: > Antti-Juhani Kaijanaho wrote: > > Don't do it without the maintainer's go-ahead. The current best > > practice is to use whatever (non-evil thing that) works for the > > maintainer. > > This "best practice" fails miserably if the maintainer is not always > perfectly responsive. As soon as the maintainer goes on vacation (or > MIA) and gets a security hole or RC bug in his package, the more > nonstandard their packaging the harder it becomes for someone to fix > the problem in it without introducing other bugs or wasting a lot of > time stumbling over weirdnesses in its packaging.
This is why I believe (have, in fact, believed since I started as a DD myself) that every developer should be familiar how packaging works in the raw "GNU make, install, gzip" world - not just in the abstract, but in practice. In my not so humble opinion, it is part of the basic competency of a packaging-oriented DD. Traditionally, I have been in favour of people using whatever helpers they felt useful, but as you point out, helpers tend to create a whole different vocabulary for packaging which then makes it hard for people not familiar with that particular helper to read and modify the rules files. For debhelper, the effect is diminished by the fact that almost all developers know it, but it is still there. Of course, it is possible that I am a relic from a past that never was and that the established core packaging competency is Debhelper, not GNU Make. I have seen indications that some developers do think like this. Obviously, I don't. I'd prefer, however, that if that is the case, then it be documented in policy. (My own rules files are basically handwritten, with the addition that I have over the years developed a GNU Make library, included in any package using it, that abstracts away most of the repetitiousness. They should still be readable by anybody who is familiar with GNU Make. I see some people who have adopted packages from me also use it for those package. Some of the packages I have adopted still use whatever system I inherited from the previous maintainer, though.) -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian
signature.asc
Description: Digital signature
