On Tue, 2006-11-14 at 18:38 -0800, Russ Allbery wrote: > > "Two different packages must not install programs with different > > functionality but with the same filenames." > > > There does not seem to be any reason to exempt shell builtins from this > > requirement. > > I think there are obvious reasons to exempt shell builtins from this > requirement, so you're going to have to present more of an argument than > this. I think this is a very strained reading of that section of Policy, > and in my opinion is "obviously" not what that section is trying to say. We have not yet exempted builtins. I am not, in fact, opposed to doing so. But I want a list of exemptions to be specific. Are you seriously saying that *any* shell builtin is exempt? That a shell may override *any* Debian behavior? > > > I conclude that any shell builtin which exhibits a different > > functionality from the official Debian test implementation > > (/usr/bin/test, as distributed by coreutils) is buggy. > > So every shell in Debian is buggy, since none of them provide all the > functionality in all of their builtins that coreutils provides. Yes, I'm happy to say that. These are not crucial bugs; Debian has lots of bugs. :) Not every bug is of critical importance, but yes, these are bugs. > This proposal as stated seems to fail a basic sanity test, namely not > declaring buggy the shell we have marked Essential and have been using for > the past 10 years over issues that no one cares about. These may be extremely minor bugs in some cases, without thereby not being bugs. I am happy to agree that these are mostly minor, some even entirely trivial bugs. Similarly, two Debian packages which install like-named binaries may have small differences in the interfaces they provide. I would be expect that probably nearly all such cases of like-named different programs have some differences in their implementations. These are all clearly bugs according to 10.1, but of course, they are not all very important bugs. > I don't believe that your proposal will help, and in fact I believe it > leaves us in an even worse situation with incompatibility between Policy > and practice than we have right now by requiring shell behavior that is > clearly not implemented by any of the shells in Debian. That's a fairly > extreme thing to do and would require extreme justification. Then make a specific list of Debian programs which shells are allowed to override, and only those, and exactly what options they are required to support at a minimum when they override them. Your proposal seems to me to be even worse. Mine says that there are lots of low-grade unimportant bugs hanging around, which probably don't need lots of attention except when cases arise where they cause real problems. Yours says that there is no bug at all in a shell which decides to override the behavior of debconf in random and unpredictable ways. > coreutils may add additional functionality to commands also implemented as > builtins, often functionality that is not horribly important and is added > mostly because there's no reason *not* to add it. I don't think it's > reasonable to expect every shell in Debian which implements builtins to > keep up with those changes. In practice, your proposal to me seems > tatamount to requiring that shells in Debian never implement builtins > except for functions like cd that can only be done through builtins. To this paragraph I simply reiterate what I say above: that something is a bug is not the same as saying that it is of gigantic importance. Why is it shocking to declare that bash has a bunch of low-grade fairly unimportant bugs? Is that supposed to be news? But if you want to exempt specific builtins, I have no disagreement with such a strategy, and the details can be worked out without much stress; indeed, I don't have much at stake at all in how the details get worked out. If you want to exempt any builtin whatsoever, no matter what it does or why, then I have a disagreement. Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part