Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
On Fri, Sep 10, 2004 at 08:19:00PM -0700, Thomas Bushnell BSG wrote:
> Clint Adams <schizo@debian.org> writes:
> > The "builtin" is a red herring. Your package will be none the wiser if
> > a shell implements a "test" conforming to the de facto coreutils spec in
> > the form of a builtin, a shell function, or something else.
>
> Quite right, but the exact same is true of debconf.
>
> My point here is that debconf and test are on exactly the same
> footing.
>
> Having specified them in Build-Depends (or relied on the list of build
> essential packages), I am allowed to expect the Debian behavior of the
> program.
>
> Which means that "test -a" is currently allowed.
>
> So, doesn't this mean that "posh" has a bug, since (I'm told; perhaps
> I'm incorrect) it implements a "test" which does NOT conform to the de
> facto coreutils spec?
>
> That suggests a new option for solving the bug I reported, one which
> is not one of my original four:
>
> Require any shell that implements /bin/sh to be required to build in
> commands (that exist as programs in the filesystem also) only in
> ways which are indistinguishable in practice from the normal Debian
> versions.
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 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).
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: