On Wed, Jun 19, 2002 at 07:59:33AM -0400, Clint Adams wrote:
> > 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?
How about we add "I'm not such an idiot to break my packages just because
I get in an argument with aj?" to the new-maintainer P&P check?
> 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.
Scenario A: Script works on bash and ash, which are the two main shells anyone
has a reason to use as /bin/sh on Debian.
Scenario B: Script works on bash and ash, which are the two main shells anyone
has a reason to use as /bin/sh on Debian.
> Why is one choice not obviously preferable to the other?
Because you're biasses don't happen to be mine.
It happens to be a lot of work to make something comply with the letter of
POSIX's minimal specification for /bin/sh, especially since it seems to
be intent on becoming more minimal as time passes, and since it doesn't
seem to worry itself too much with existing BSD or Linux systems.
It's also a lot of work to do heaps of other useful things in Debian: make
it release faster, improve it's security, have all the neat new GUI apps
get a similar degree of reliability as our server programs tend to have,
and a bunch of other things. I can see obvious benefits from the latter,
I can't see *any* benefits from being as obsessive as you're being with
the former.
Well, no, that's not really true. I don't mind having random scripts
work on random other Unices, that's neat. And I wouldn't overly mind if
you'd taken the time to do a little polite write up of why "kill -9"
isn't something we should do, post it to -devel along with citations
people can easily check to the appropriate standards, and then file
minor or wishlist bugs about it.
Because, to be blunt, there are a million things that're a million
times more important than whether you can use something other than bash
as /bin/sh.
> > 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.
Which is what policy is, if you ask me.
> Policy is useful in that it ensures consistency and interoperability.
No, the professionalism and commitment to excellence of Debian maintainers
is what ensures that.
> > 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 you should look again at all the packages you've been filing bugs
against. If you make /bin/sh something else, and lots of stuff breaks,
that's evidence that you're missing a needed feature.
You do realise we use policy as an aid to developing a distribution,
not develop a distribution as an aid to writing policy, right?
> > 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.
That's nice. In future, before filing bugs against a bunch of packages
for something you think's a policy violation, gain a consensus on -devel
about it first. It's a simple rule, and it prevents a lot of annoyance.
You'd think the people who insist on rules being followed to the letter
would bother to read and follow them themselves, no?
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
Attachment:
pgpb6_VwZbCat.pgp
Description: PGP signature