On Thu, Oct 29, 2009 at 03:54:23PM +0000, Matthew Johnson wrote: > On Thu Oct 29 15:58, Michael Banck wrote: > > On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote: > > > Are there any serious objections against just overriding and ignoring > > > the Linitan warning about not having "make -f" in the shebang line?
> > As long as you don't have an objection against having serious bugs filed > > and your packages not be part of a stable Debian release, I guess not. > put me in the camp that doesn't think this is necessary. If it behaves > precisely the same way as a makefile which does have that shbang line > when compiling the standard Debian package I really don't think there is > a problem with this. I agree, Policy seems to be overly specific here; it should concern itself with *interfaces*, not with the internal details. I don't think the fact that someone can find examples where ./debian/rules vs. make -f debian/rules will behave differently is a justification for this level of constraint in Policy, when those examples are corner cases that have nothing to do with how we build packages. That said, I think it's entirely inappropriate for individual maintainers to cook up clever debian/rules that violate Policy as written. Policy is the repository of our shared consensus for how packages must work, and maintainers should not presume to ignore Policy just because they think it's wrong. Debian Policy embodies 15 years of accumulated experience; and while it still has bugs (and presumably always will), the way to deal with those bugs is to resolve them through the public policy process, not to be a cowboy and upload non-compliant packages because you think you know better than Policy. And, until Policy /is/ amended to say vdr's usage is ok, we should continue to treat this behavior of vdr packages as a Policy violation of the appropriate severity. Which I don't agree is "OMG critical block it from the archive", I think vdr should be allowed to use a lintian override for this error. (Other packages that hit this lintian error are probably buggy under any reasonable formulation of the Policy requirement, and should therefore be regarded as broken and kept out of the archive regardless - but it would be non-trivial for lintian's static checking to distinguish vdr from those other packages...) On Thu, Oct 29, 2009 at 07:26:42PM -0300, Felipe Sateler wrote: > On Thu Oct 29 15:58, Michael Banck wrote: > > I'm also against the suggestion which reduces debian/rules to: > > ifeq (....) > > include real-debian-rules.mk > > else > > include alternate-debian-rules.mk > > endif > > At least the VDR solution means that if I just care about fixing the > > package in normal Debian mode, I can look at Debian rules and see what's > > going on, not have to go look at some other file which contains the real > > debian/rules. > Not true. If you were not familiar with the special script, you would > have to read that entire script to understand what it does. OTOH, in the > make-only approach it is easier to discard the contents of > alternate-debian-rules.mk entirely (since that special variable is, > well, special). We have plenty of packages in the archive that have this problem while being perfectly compliant with Policy's shebang requirement. I don't see any point in trying to use the specter of obfuscated code to justify this requirement. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
