Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
On Sat, Sep 11, 2004 at 02:01:48AM -0700, Thomas Bushnell BSG wrote:
> Colin Watson <cjwatson@debian.org> writes:
> > Why not forget about doing this in 10.4, and simply invoke 10.1?
>
> I think you're on the right track here in identifying perhaps another
> solution to the problem. This might produce an option which is a
> hybrid of ones on my list; something like the following. Let me
> rehearse it just to make sure I understand correctly. We would say
> somethnig like:
>
> "Except for the following shell builtins, a Debian shell installed in
> /bin/sh may not buildin any commands provided by packages of priority
> Optional or higher, unless it does so in a way which is functionally
> equivalent to the normal version."
I think I'd be inclined to avoid mentioning package priority at all
here; of late it's been quite weak, and I don't think we'd want bash
providing, say, scsh (which is extra) without some kind of notice.
Yes, this means that introducing new shell built-ins is difficult. It
doesn't mean that they can't be done, only that, per the language of
10.1, the shell maintainer has to go and talk to the maintainer of the
other package and to debian-devel and decide which one gets to keep the
name. I think that's exactly the behaviour we want.
I think the right language is something like:
Except for the following shell builtins, additional commands provided
by a Debian shell installed in /bin/sh shall be considered to have the
same status as executables in the filesystem for the purpose of name
conflicts with other packages. As a result, they must either provide
the same functionality as the other program or else discuss with the
other maintainer and debian-devel which one should be renamed.
> > In the case of 'test', we are at liberty to choose the desired
> > interpretation. Since very substantial numbers of existing /bin/sh
> > scripts in Debian use the -a and -o primaries (including scripts on
> > users' machines, so we wouldn't want to delete this functionality from
> > existing shells either), forbidding them straight away is not a good
> > idea, but they could easily be declared deprecated in /bin/sh scripts.
>
> The way to do this is to forbid them right away, but to make
> compliance not release critical for a while.
test -a/-o isn't release-critical at the moment anyway.
Release-criticality is determined by the release managers, not the
policy manual, and this issue clearly isn't mature or agreed-upon yet
among developers nor does it cause widespread breakage for most users.
It is not "release-critical but ignored for sarge" either, as Clint
suggested. That status is reserved for a very limited class of bugs; the
only thing that comes to mind is DFSG-freeness of things other than
code, and that status implies that the issue will become
release-critical in the next release. test -a/-o is simply not
release-critical at all. Issues of shell policy will only become
release-critical when there's general agreement on the correct policy
decision and a clear strategy for fixing most of the conformance bugs in
a reasonable time. At that point, they will be documented in the release
policy.
The maintainers of the policy manual have always taken a similar
attitude, so forbidding it right away wouldn't happen; rather, it would
be a "should not" for the moment until general conformance is sorted
out.
> > I think my view is that the simplest approach is to rely on 10.1 to
> > dispose of the worst clashes and then explicitly specify deviations from
> > POSIX in controversial cases. This also happens to be in line with the
> > current approach taken by policy for echo(1).
>
> I think this is an excellent proposal, the more I think about it. Let
> me sleep on it a bit, and if people have objections or see problems,
> please let me know. I think it eases up on the justifiable concerns
> that many have with the list-of-shells approach; I preferred that only
> because I didn't see any solution I like better, and I think I really
> like this one.
OK, glad it made sense. Early morning suggestions from me aren't always
coherent ...
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: