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. The statement "Posix-compatible" was apparently intended by the authors of that part of the Policy Manual to do that work for us, but it doesn't. That doesn't mean the work is valueless. > > I personally don't see a current need to state in Policy "don't add shell > builtins that override common commands without providing the features of > those commands"; I think that problem can be adequately dealt with by > normal bugs and the application of common sense. 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*. > I disagree with your proposal and do not believe it is the direction we > should go. Earlier, you said that it was an important thing to work out, but that you wanted to work on this one first. I don't think you changed your mind however, I think you misunderstand "my proposal". My proposal is simply to provide a list of which Debian commands shells can override with incompatible builtins. If you think that we can just assume that all existing shells do nothing bad in this regard, it should be about five minutes work to find out what all their builtins are and form the union of that set. > > The absence of a requirement in Policy is not a positive declaration that > something is not a bug. I do not want to document every possible bug in > Policy; I don't believe that's a useful use of resources. No one has to > my knowledge uploaded a shell intended for use as /bin/sh that overrides > debconf in random and unpredictable ways, and I believe the likelihood of > anyone doing that and then being sufficiently convinced of its technical > merits as to demand citing chapter and verse of Policy to resolve the > situation is exceedingly low. 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. 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. Thomas
signature.asc
Description: This is a digitally signed message part
