> Imagine, people actually wanting a justification beyond "random document > X says so" for bugs filed at a "serious" severity.
How about I litter all my #!/bin/sh postinsts with useless zshisms? Then when people file bugs, I say "Haha, fuck you; it works for me." > debian-policy -- says you should do something one way means *absolutely > nothing*. The *only* reason to do things one way instead of another is > because doing them that way is *more effective*. I see. You don't see adhering to standards as being effective. Let's see. Scenario A: Anthony Towns puts kill -s KILL $pid in preinst of netkit-inetd. Script works on all POSIX-compliant shells. Scenario B: Anthony Towns puts kill -9 $pid in preinst of netkit-inetd. Script BREAKS on some POSIX-compliant shells. Why is one choice not obviously preferable to the other? > debian-policy is *only* useful in that almost all of its comments are > time-tested instructions on how to do things in the most effective way. No. That would be a best practices document. Policy is useful in that it ensures consistency and interoperability. Or are you suggesting that the policy document is really just a shadow of some real policy that exists only in the minds of the developers? > If you really want a document that says what features of the shell we > rely on, that's fine: write one. Base it on SUS, or POSIX as necessary, > but don't pretend POSIX or SUS is correct as it stands, least of all > when you find evidence that *directly contradicts* such an assumption. The only evidence I see that directly contradicts such an assumption is the dearth of shell features mandated. > Perhaps "policy isn't a stick" isn't the best way of phrasing these > things, maybe a better way of phrasing it is "policy isn't the law". Every > time we find a contradiction between what we think is the right way of > doing things and what policy, POSIX, or whatever says, policy should be > put on trial just as much as any given developer. Fine. That doesn't mean you should go around pretending that there's an exemption for 'kill -9' in Policy. > Surely we're all here looking for the *right* way to do things, not > merely the documented way. Of course. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
