On Sun, Mar 18, 2012 at 09:30:47PM -0700, Russ Allbery wrote: > My impression is that discussion on this bug has wound down, and that it's > unlikely that any new information is going to come up. To me, that > implies that we should call for a vote.
I'm pretty sure I'm unconstitutionally late for this, sorry (I've had a busy week and have not been checking Debian mail much). But just in case it matters: > Based on Ian's last response, I think the ballot has two options plus > further discussion, since I'm quite sure that we're not going to outlaw > dh: > > A. debian/rules is not required to be a makefile, only to implement the > same interface as a debian/rules file implemented as a makefile > (including handling of arguments and exit status). Debian Policy > should be updated to change the requirement to a recommendation, and > new versions of the leave package should be permitted to be uploaded to > the archive without changing debian/rules to be a makefile. > > B. The Technical Committee affirms the Debian Policy requirement that > debian/rules must be a makefile. All packages in the archive, > including leave, are required to follow this requirement. This > makefile may, as is common practice, delegate implementation of its > targets to a script. > > C. Further discussion. I vote BAC. While I understand the position that B can lead to pathological results, in practice I'm not aware of this happening in practice, or if it is then it's a trivial number of cases; developers generally use delegation to scripts to create more expressive power, as in dh, not to subvert the usual norms. Thus, I don't think the situation created by this Policy requirement is objectionable enough to overrule it, even leaving aside the benefits of standardising on a Makefile. I will admit to some curiosity as to whether Josip would in fact comply with this ruling by "what amounts to trickery", as Ian puts it, or whether he would decide to do something that more developers will be familiar with instead. Had I spent more time thinking about this, I might have tried to articulate a position for the ballot in which delegating implementation of debian/rules to scripts is permitted provided that the intent of such scripts is to create an abstraction layer that could be used by multiple packages, which would distinguish "I want to contribute a new packaging helper tool to the project" from "I'm trying to work around this requirement and use my favourite language instead". However, Andreas is probably right in pointing out that the technical committee is not the place to do detailed policy design. If Ian feels that this would be a useful middle ground between our positions, I'd be happy to take something like this to -policy and we can hash it out there. -- Colin Watson [cjwat...@debian.org]
signature.asc
Description: Digital signature
