Re: Proposed new POSIX sh policy
Thomas Bushnell BSG <tb@becket.net> writes:
> On Tue, 2006-11-14 at 18:59 -0800, Russ Allbery wrote:
>> I think this would be a great deal of work for little useful benefit.
> Why? Surely it would be useful to know what the differences are between
> various shells.
I believe that such a document would be useful, but I'm not convinced that
it's in the scope of Debian Policy or that maintaining such a document
(it's not a trivial amount of work) is a useful use of the time of the
Debian Policy team.
If you would like to maintain such a document, by all means, I encourage
you to do so. It would be useful to have. If you don't feel that you
personally have time given your other priorities, well, I feel the same
way.
> I feel as if we are going in circles. We already have lots of shells
> which have builtins which override common commands (test, for example)
> without providing the features of those commands. This thing you think
> is so obvious it doesn't need stating is *causing problems*.
Could you give some specific examples *other* than test -a/-o?
The problem sparking this thread and my initial work on a Policy patch is
not a problem caused by shells with builtins; it is, in fact, not a
technical problem at all in the sense that no user has had their system
broken by the use of test -a/-o or local unless they were intentionally
running a POSIX compliance test suite as their /bin/sh. It's an
inconsistency problem between our current Policy document and the manifest
reality of what's done today in Debian.
If I'm understanding what you're saying, you seem to be raising a
different problem, which is that apparently packages or user operations
have broken because shells have implemented builtins. Is that correct?
If so, could you point me at the problem so that I can understand why you
feel that Policy is the correct venue in which to fix it?
(I know that this has probably been discussed at length in the past, but
it would really help a lot to have a brief summary of the specific
problems that this would address extracted from whatever previous
discussion there is in the archives.)
> My proposal is simply to provide a list of which Debian commands shells
> can override with incompatible builtins.
And, as I understand it, a statement that shells are not permitted to
override any other commands except for the ones listed. If that
understanding is correct, then yes, I disagree with the proposal to state
such a thing in Debian Policy and I don't believe that's the direction in
which the Debian Policy shell section should go.
First, I think that maintaining such a list is a fair bit of work (bash
has, at a quick count, 56 builtins and presumably adds more on a
not-infrequent basis). Second, I don't believe that a conflict between a
bash builtin and a minor command provided by a priority: optional package
is a bug at the same level that a conflict between two packages providing
the same binary is, since the former does not prevent bash and that
package from being co-installed, which is one of the major reasons for the
existing 10.1 policy about binaries. Third, I believe that this problem
is mainly theoretical and investing effort in writing a policy, testing
compliance with that policy, and maintaining the words in the policy
manual going forward is more effort than the problem warrants.
If you can show that the problems caused by the current lack of a policy
are sufficiently important to warrant a stance taken in Policy, that would
remove my third objection, but I belive the other two would remain. I
think we'll be able to find some other way of addressing those potential
problems.
And none of this is going to help with test, since I cannot imagine a
shell policy that would say that shells cannot override test. That's just
about the *first* thing that people build into any shell that's expected
to have reasonable performance.
> We have had shells which override Debian programs in a variety of ways.
> Indeed, we are dealing *right now* with some disagreement about which
> overridings of test are ok and which are not.
I don't believe we are. If you're arguing that overriding test is not
okay, I believe you're the only person making that argument. I'm only
debating what features are required to be in the test builtin in the
shell; I would never dream of arguing that the shell should not have a
test builtin or that it should be required to behave the same as
/usr/bin/test.
> So I find it a little disingenous if you think that we can just all
> already know which overridings are ok without any actual decisions.
I don't think that. I'm arguing against putting a statement into Policy,
which as I just pointed out is not the same thing as saying that something
is okay.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: