On Tue, 2006-11-14 at 22:15 -0800, Russ Allbery wrote: > 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. Heck, I'm entirely happy with Manoj's suggestion to drop the whole damn thing, and simply say "/bin/sh will be bash." If you want simplicity, that's it! > > 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? No. I'm saying that the existing noticed problem (test) is *better* solved by something other than a pseudo-solution. A good solution might be to say something like Manoj's solution, or *something* that does more than say "let's pretend that the words 'Posix-compatible' mean something!" Let's try and solve the problem, rather than push it under the rug and hope it doesn't come up *yet again*. Again you say? Well, we pushed it under the bed with echo, and now we're going to do that with test. How about we actually decide what we actually want? Right now, we say "we want to make it possible to install any Posix-compatible shell as /bin/sh". You want to tweak that slightly. Regardless, *it's a meaningless sentence*. We *don't* want that to be possible. > > 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. So you think it should be entirely open-ended? Why is 10.1 there at all? Why should 10.1 have this rule, and shell builtins have *nothing* like it? > 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. Yes. People seem to think that it is a bug when packages depend on coreutils/bash features of test, and file annoying bug reports about them. They will happily continue to do so for any features that they (mistakenly) think are "bashisms". Why are we wasting *any* time with this silly enterprise? > > 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. What's wrong with saying "you must build it in the same way, so that the builtin is compatible with the programs in the filesystem"? This is *exactly* what Posix expected people to do. Indeed, it may well be noncompliant with Posix for a shell builtin to have a different behavior than the programs in the filesytem, but I'm not sure. I would have to study the language very carefully, and I can't recall how the relevant sections are worded. (It's difficult to get the answer trivially, because Posix doesn't even mention builtins at all.) > > > 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. We have a disagreement about *which overridings* of test are ok and which are not. You think that overriding test is ok provided that -a is supported. I think that -a and () should be required. Some think neither. We disagree about *which* overridings of test are ok. Everyone agrees that it's ok for a shell to override test. The question is *which* overrides of test are ok? I would much rather see us *not* mandate particular shell script rules, and *instead* mandate rules for which shells are allowed to be used as /bin/sh. Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part