Re: bash exorcism experiment ('bug' 762923 & 763012)
Russell Stuart <russell-debian@stuart.id.au> writes:
> 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".
We had a lot of discussions about this on debian-policy at the time. I
suppose it's possible that I'm misremembering, but I'm pretty sure I'm
not. That's specifically what the phrasing "scripts may assume" is trying
to drive at: this is the functionality that you can assume that /bin/sh
has, which in turn creates a requirement for /bin/sh.
I'm sure the wording could be clearer. Wording always can be. :)
>> 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.
I'm not sure how you meant this, but to note, this sentence made me very
sad, since it felt like you believe I'm being intentionally dishonest with
you. I'm really not, although I'm not sure how to convince you of that.
Maybe you actually meant to say "misremembering" (something that could be
accidental) rather than "re-writing" (which is usually taken to be
intentional and deliberate)?
Anyway, I think the key misunderstanding is here:
> 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.
That's not what I was getting at at all. Rather, that portion of the
policy received a lot of work and attention, some rewordings, and a lot of
expansion during the time period when the project was working on replacing
/bin/sh with dash. The specific list of exceptions was expanded based on
that work; they were the things that we chose to accept on top of a POSIX
shell because getting rid of them would have otherwise have been too much
effort. That section of Policy was written hand-in-hand with writing
checkbashisms and with pushing the archive towards working with dash.
> 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.
Policy 10.4 is a key part of the specification for checkbashisms and the
justification for the mass bug filings. These were not independent
efforts.
> 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.
We did not ever go all the way to verifying that everything in the archive
would work with a shell that exactly conforms to the minimum Policy
requirements and no more. The farthest we ever got was to get dash to
work. I thought that's what you were getting at when talking about
testing, and I was agreeing with you that we didn't test against non-dash
shells. What I don't agree with is the idea that Policy should therefore
just say that scripts have to support dash, rather than saying what it
says now. (I thought you were arguing for that; maybe I'm wrong.)
> 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.
I don't think it *was* particularly helpful prior to when we did the work
of switching to dash. But during that effort, Policy was quite helpful in
communicating what script writers could rely upon, and in driving
specifications of other tools, like checkbashisms. And providing sanction
to mass bug filings.
Now that dash works with the archive, this section of Policy is no longer
as important, because we're not doing a major project based on it. It's
there for documentation, some people read it, it's occasionally used to
settle disputes, but I expect most work is just checked against dash.
Yes, we never drove all the way to implementing exactly what Policy says
that we should do. I get how this is unsatisfying; we're saying something
that isn't exactly what we're doing. I think I'm falling more on the
aspirational than the descriptive side for this particular part of Policy,
but I can understand why that's uncomfortable.
> 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.
I don't think it's a good thing. I think it's a prioritization decision,
and I also think it's partly an artifact of the fact that, for whatever
reason (I think there are a lot of possibilities), the level of work that
we put into Policy is clearly not sufficient to keep up with the things
that we want to standardize for the archive. So sections of Policy that
are not actively focused on are often not clear about their exact status
in the archive, and the hard conversations about where we want to fall in
the aspirational versus descriptive line never happen, because they're
very difficult to reach consensus on.
I don't have any great solutions for this, and I'm not saying it's a
wonderful situation to be in. I'm just trying to be realistic about it,
and I don't think it's a horrible place to be.
> 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?
Oh! I didn't realize or internalize that you were proposing switching the
default shell to posh from dash. Yes, that would certainly improve our
compliance with Policy considerably.
The problem that I have with that is not on that front, but rather that
there are various reasons for picking a particular shell, and I'm not sure
that posh is the right choice along other axes. But I'm not personally
opposed to doing this. If the speed is comparable, I really like the idea
of having a minimal shell as /bin/sh, since that would make it far easier
for people to switch to any shell that supports a strict superset of
functionality.
>>> 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?
No. That's not what I said at all. I said that the idea that it should
be obvious what you have to do to comply and it should be automatically
verifiable that you've complied are wonderful ideals (I mean that
completely seriously and non-ironically), but are not principles that we
generally use in writing Policy. It's simply not possible with current
resources and verification tools to achieve that for more than 40-60% of
the things that go into Policy in my rough estimate. Now, I've not worked
on Lintian in a while, and other people have done a ton of great work in
making it stronger, so that percentage may now be higher, but I'm sure
it's not 100%.
I'm not saying that's a good thing at all. I'd love for that to be
false. But that's the world we actually live in. One of the things that
we've always been clear about in the Lintian documentation is that Lintian
does *not* check all of Policy, cannot check all of Policy, and clean
Lintian results do not mean that your package is Policy-compliant.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: