On Sun, 05 Nov 2006 19:41:40 -0800, Russ Allbery <[EMAIL PROTECTED]> said:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>> This flows from the Release policy. Not specifying /bin/bash in
>>> scripts is not considered a RC bug.
>> I can try to propose better language for this. I think that using
>> pure bash-specific constructs not found in dash in /bin/sh scripts
>> should actually be an RC bug, but using test -a or test -o should
>> not. I think we need to say that /bin/sh scripts are permitted to
>> use POSIX shell capabilities plus a short list of additional
>> capabilities that everything other than posh also implement.
> Here's a proposed patch. What do people think about this approach?
> I know there was an inconclusive Policy discussion a while back
> about how best to deal with this issue. As you can tell from this
> patch, I favor the approach of documenting the specific features
> that we require and assuming that their semantics are sufficiently
> clear in practice.
OK. How about we again step back, and examine the rationale
behind this, and the use cases that we intended to support? Look,
bash is essential, and ships as /bin/sh; nothing is required as far
as systems integration requires in order to specify anything in
policy, really -- policy could just take the approach /bin/sh ==
bash, and stop worrying about bashisms or any standards compliance
beyond what bash already supports.
Why don't we do that? Because people wanted to have a
different shell that can serve as /bin/sh. What purpose does it
serve to allow that? We can't, in all honesty, say that any disk
space is conserved, since bash is essential, it is too deeply rooted
in all places in our system to be casually ripped out.
One thing I see happening is that replacing bash as /bin/sh
might make script startup ties a bit faster, at the expense of soe
of the built in facilities and extensions present in bash.
So, the goal seems clear: to specify enough in policy so that
at least maintainer scripts do not break if /bin/sh is not bash -- or
that they use /bin/bash as the interpreter.
So why not just specify all maintainer scripts just use
/bin/bash? I am not sure. Perhaps because allowing scripts to specify
/bin/sh would allow then to be sped up a trifle when /bin/sh is a
nimbler shell? Is this worth the complexity? we speed up install
times of packages a wee bit at the expense of a much more complicated
policy document? (I know some people think we can move bash out of
Essential one of these days, and well, I think that is mere wishful
thinking and a pipe dream).
I personally don't think so.
It is my opinion that we would be better off dumping this
whole shell specification thing in policy, standardizing on bash, and
let it go.
It would, at one fell swoop, solve the problem Thomas hinted
at before, about our specification allowing shell to randomly shadow
other commands on the system.
If people really think we need to keep this problematic part
in policy, please put forth you rationale, and the use case you think
you want supported, and why it needs to be policy at all (as opposed
to a developers reference good practice thing).
manoj
--
apostrophy: when your apostrophe atrophies. David Bedno
<[EMAIL PROTECTED]>
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
