[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Thu, 2014-10-02 at 20:43 -0700, Russ Allbery wrote:
> A lot of people miss this about Policy 10.4.  People seem to think that
> Policy 10.4 is about requirements for shell scripts.  But it's just as
> much a standard for /bin/sh.

You wrote it, so I guess you get to say what it means.  But if you
hadn't said so just now, I'd be using the "People"'s interpretation
rather than yours.  10.4 is after all titled "Scripts", not "a sh
language definition" or some such.  Where it does define the shell
language, it does so in in this context: "Scripts may assume
that /bin/sh implements ...".  So to me it is addressing itself to
script writers, not sh language designers, and to extent it describe the
the shell language standard is does to purely to inform the script
writers what environment they can expect when they use "#!/bin/sh".

> This was important when we were debating switching from bash to something
> else, and needed to be clear about what behavior the rest of the
> archive could expect /bin/sh to always satisfy.

I looks to me like you are re-writing history.  Right back in the policy was pretty much what it was now.  "#!/bin/sh" scripts had
to be POSIX - albeit with less extensions than we allow today.  If
policy was so good at informing the debate about what "#!/bin/sh"
scripts did, I'd be surprised there was much in the way of a debate.
You could have switched to any shell that implemented the POSIX subset
with very little pain.

So this statement of yours: "we ... needed to be clear about what
behavior the rest of the archive could expect /bin/sh to always satisfy"
is puzzling, because there was pain.  Everyone knew what /bin/sh did -
it was defined in the bash man page.  Since bashism's worked just fine,
and evidently regardless of what policy said no one cared whether you
used bash'ism or not so they were used with gay abandon.  If as you
suggest Debian relied on policy for a clear description of how /bin/sh
scripts behaved, it was in for a rude shock.

It didn't of course.  Debian got the clear description it needed by
writing automated checkers like checkbashism, followed threats to
change /bin/sh away from /bin/bash, mass bug filings and finally in 2011
doing it.

I am not criticising any part of this process.  Standardising its shell
language was huge undertaking for Debian, and pull it off almost without
a hitch.  It's the sort of thing that makes me proud of the project.
What I am questioning is your assertion that policy that wasn't verified
let alone enforced was somehow key to it.

> I think people often don't realize what Policy is actually about, or what
> it can (and can't!) accomplish.  Policy is more a way for us to coordinate
> our work and agree on what we're actually talking about than an enforced
> set of rules that are followed.

Again, you've lost me.  Yes, policy that is followed and policed is very
useful.  It is very nice have man pages for almost everything.  For me
its essential I can rely on Debian's copyright policing.

But to use this example again, you are saying the agreeing that
"#!/bin/sh" scripts shall be POSIX shell scripts, and then largely
ignoring it for 10 years because it is unverifiable was helpful to the
project?  I don't see how it saved anyone any time.

> So yes, there's a lot of Policy that is ignored in practice.  You can take
> various attitudes towards that.  You can view that as meaning Policy is
> (at least partly) worthless because we're not enforcing it.  Or you can
> decide that Policy is more aspirational than descriptive.  Or you can
> focus on the change Policy has helped make happen.  I think all those
> viewpoints are accurate to a degree.

OK, but realise you are making life hard for some of us here.  Perhaps
you, as one of the policy author's know what bits are hard and fast
rules and which bits are purely aspirational.  I don't.  I guess if we
less knowledgeable folk finding ourselves disagreeing with some policy,
we can try assuming it's aspirational and ignore it.  Yes, it made me
cringe to write that.  But you are telling me it is the way Debian works
now.  And I get the impression you think this is a good thing.

> As bad as you think the compliance with Policy 10.4 is right now, I
> guarantee that the prospects of being able to use something else as 
> /bin/sh would be way worse if we did what you suggest.

Ah!  And here we is our fundamental point of difference.  It is beyond
me how you could think that could be so.  So much so that I'm doubting
my comprehension abilities.

I do have this right - the goal is to ensure "#!/bin/sh" scripts use a
standardised subset of the shell languages out there?  That way should a
user change a different /bin/sh, he can be reasonably sure it will work
if implements this well defined subset.  (And yes, I acknowledge the
subset is well defined in the current policy - well done.)

To achieve that end you are proposing all we do is ask developers nicely
to use that subset.  The alternative I am proposing is to link /bin/sh
to a program that implements just that subset (which it seems posh
does), so their script bugs out if the policy is broken.  And you are
telling me you guarantee that the prospects of this working are better
under your proposal than mine?

>> Which is to say it should be obvious what you have to do to comply,
>> it should be automatically verifiable you have complied,
> This is a lovely idea that has very little relationship to reality and
> has not had much relationship to reality for as long as I've been
> involved in Debian.

It's surprising to see a lintian contributor say he thinks automatic
verification and subsequent enforcement aren't worth much.  Do you
really think that?  Anyway, even if it does not have much relationship
to your reality, it sure has a relationship to mine, and mostly because
of lintian.  A few weeks ago I was forced to change something in a
package in a way I strongly disagree with.  It was noticed because of
lintian (maybe one of your checks?), and later enforced by the FTP

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: