Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
On Sat, 11 Sep 2004 09:47:42 +0100, Colin Watson <cjwatson@debian.org> said:
> Why not forget about doing this in 10.4, and simply invoke 10.1?
> Two different packages must not install programs with different
> functionality but with the same filenames. (The case of two
> programs having the same functionality but different
> implementations is handled via "alternatives" or the "Conflicts"
> mechanism. See Maintainer Scripts, Section 3.10 and Conflicting
> binary packages - Conflicts, Section 7.3 respectively.) If this
> case happens, one of the programs must be renamed. The maintainers
> should report this to the debian-devel mailing list and try to
> find a consensus about which program will have to be renamed. If a
> consensus cannot be reached, both programs must be renamed.
> While it says "install programs", it's clearly in practice
> irrelevant whether this is by means of installing an executable file
> in /usr/bin or by implementing a new built-in. A shell implementing
> a 'debconf' command would be buggy (policy "must", and
> release-critically since something similar is also in the release
> policy) if it did not have the same functionality as the existing
> one, to whatever degree of accuracy is appropriate for the case at
> hand.
> You have to assume a grandfather clause for variation between
> existing built-ins in shells to make this sane, but that seems
> perfectly in line with the mention of alternatives in 10.1. In
> addition, shell built-ins might reasonably be held to a very high
> standard of accuracy when clashing with programs on the filesystem,
> since they effectively replace programs on the filesystem for
> scripts interpreted by that shell without the presence of a
> Conflicts:. However, all of that is essentially a matter of
> interpretation of policy.
> 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.
I also think that this language supplied by Colin is the best
bet so far. It does not require policy to specify and maintain a list
of acceptable shells, it does not require any new candidate to be
bug-for-bug compatible with current lists of shells (as would have
been needed for option 2). And, unlike option 1, it would still be
possible for new candidates to be added to the system (requiring
#!/bin/some-shell to be hard-coded in all scripts would make it
impossible for a sysadmin to substitute a new shell, even if it would
have otherwise worked).
----------------------------------------------------------------------
10.1
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.
Note:
A Posix-conformant shell is allowed to build in *anything*, and if
it's not a Posix-specified utility that's being built in, then it can
have *any behavior whatsoever*. The presence of two commands with
conflicting behaviour adds an unacceptable uncertainty when scripts
are executed, and this has to be resolved.
----------------------------------------------------------------------
If we have a rough consensus on this view, we can move ahead.
manoj
--
"I got rid of my husband. The cat was allergic."
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: