Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
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."
And then we would list the historically relevant exceptions, like
test; that's the grandfather clause you describe. Those would be
required to implement the Posix behavior, but would not be required to
implement additional behavior.
Now this is fine for the problem of shells which could override
arbitrary things; because this is a restriction on the shells in
/bin/sh, scripts are allowed to assume that the restriction is being
followed. I also think it cuts the right line, which is not between
Posix utilities and other utilities, but rather between those we
choose to grandfather and those we do not.
This doesn't quite solve the whole problem however, because it allows
for variations in the grandfathered commands, and it doesn't say what
a script is allowed to assume there. So we'll still need something
like a statement that a script may not rely on Posix extensions to any
of the commands where a shell can have a variant builtin.
> 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.
> 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.
So let me sleep on it a bit, and then I'll try writing exact text for
an amendment to Policy that will encapsulate this idea.
Some research is needed here too, to enumerate the list of builtins
that need to be grandfathered. Can someone volunteer?
Thomas
Reply to: