Re: RFD: Essential packages, /, and /usr

[Clint Adams <schizo@debian.org>]

> 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 debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org