Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)

[Thomas Bushnell BSG <tb@becket.net>]

Clint Adams <schizo@debian.org> writes:

> I'll try saying this a different way.  Expecting "debconf" to not be a
> shell builtin is not "relying on a shell feature".

Ok.  But then likewise, expecting "test" to not be a shell builtin is
not "relying on a shell feature".  

My package expects test not to be a builtin, and restricts itself to
the features of Debian /usr/bin/test.  It happens to work as well if
the shell implements a consistent builtin, but it certainly does not
rely on this.  What it relies on is the disjunction "test is either
not builtin, or is builtin compatably with /usr/bin/test."

Which is just the same as "debconf is either not builtin, or is
builtin compatably with /usr/bin/debconf."

> If you have a list of shells, you need a decision-making process each
> time you want to add or remove an entry from that list.  If you happen
> to add an entry, you risk making an indeterminate number of packages
> instantly buggy.  If a shell on the list changes behavior, it is still
> on the list, and you risk making an indeterminate number of packages
> instantly buggy.  In this scenario, a shell on the list can do any
> ridiculous thing and it will not be buggy; other packages will be.
> Even now, if a #!/bin/bash script fails to run on bash 3, it isn't
> necessarily clear where the bug lies.

Quite right; this is the downside of the list-of-shells approach.

But consider: Suppose the bash maintainer decides to add a builtin
called "scsh", which turns on a special "screen shell" mode.  

And suddenly, any package that uses the scsh program will fail!  There
is a bug here somewhere; either in the package or in bash.  But the
current policy 10.4 makes entirely unclear what to do.

It is this problem which my bug report is intended to address.  The
list-of-shells approach clarifies, but other approaches would as
well.  "Just ignore it" doesn't clarify.

Nor is it clear, because, for example, it doesn't specify how to
understand the test -a situation!

Thomas