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

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

Russell Stuart <russell-debian@stuart.id.au> writes:
> On Thu, 2014-10-02 at 18:05 -0700, Russ Allbery wrote:

>> Up until dash changes, and then you have absolutely no idea what to do
>> with that sort of policy.  There's a reason why no standards document
>> I've ever seen says something like this.  The ISO C standard isn't
>> going to say that anything that compiles with gcc is valid code.

> Correct.  But we aren't we aren't ISO C, or POSIX and we aren't in the
> standards business.  We are in the business of producing working
> reliable systems.

Actually, I think Policy *is* in the standards business.  At least, I'm
not sure what business it would be if not that.

> Why have policy 10.4 at all?

To set requirements for what shells can reasonably ask to be made

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.  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.

It would be nice if it would continue to be useful on that front.  Having
a system with mksh as /bin/sh would be a good thing to make possible.
Now, obviously, there are a lot of things that would be nice to have, and
maybe that one isn't worth the effort.  And maybe the severity in Policy
10.4 is overstated compared to what we're actually willing to commit to.

But the point of Policy 10.4 isn't quite what people think it is.  It's
really there to make it possible to not use bash as /bin/sh, and by
extension to at least entertain the possibility that we could use
something else later.

Now, you may feel that the way that it tries to accomplish that goal isn't
the best, and you might even be right.  In its defense, however, I will
point out that, under that policy, we switched from bash to dash (with a
lot of help from Ubuntu, to be fair), something that many people thought
we'd never be able to do.  So in that sense Policy 10.4 succeeded quite
well in its major goal.

> I can also tell you how "what to do with that sort of policy" applies
> the current policy.  What is done is we have the occasional "spat" about
> bash'ism and discussion on shell syntax.  Having bashism's (or not) is
> NOT the same as working.  Yet, that's about the best we can do.  Thus
> the policy is not robustly and objectively enforced (and worse, can not
> be).  brian's observation should come as no surprise: when you configure
> Debian with /bin/sh conforming strictly to 10.4, Debian doesn't boot.
> Surely you aren't going to say this is an example of policy working
> well?

No, of course not.  However, it worked well enough to switch /bin/sh to

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.  There's *lots* (and I mean *lots*) of
stuff in Policy that cannot be enforced and is not checked at all.  I
know -- I spent a lot of time working on Lintian trying to write tests for
as much of Policy as I could.  I would guess that I was able to test for
only about 40% of the requirements added in any new version of Policy.

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.

> AFAICT defining posh as the shell all "#!/bin/sh" scripts must work with
> is better in every way, and where ever possible all Debian policy should
> be like that.

Unless we ever want to let people configure which shell is /bin/sh on
their system.  Which is something that a *lot* of people wanted at the
time, and that I think some people still want.  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.

Maybe that's not as important as the goals that you raise, but I think
you're discarding more here than you seem to realize.

> 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

I check compliance of my scripts against Policy 10.4 by looking at them
and seeing if they use non-POSIX constructs other than those listed there.
Do I miss stuff because I don't actually test with posh?  Yes, probably.
Do I miss very much?  No, actually, I seriously doubt I do, since nearly
all of my scripts are pretty simple.  Has Policy 10.4 helped me personally
to know which constructs I can use?  Yes, absolutely -- I use it all the
time.  So for me in my work as a Debian Developer, it's working.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: