[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



(I hope I got the addressing right on this.)

I probably should not jump into this, as this thread is already quite long
and I'm not sure I'm going to remember everything that was previously
raised, but it feels like something's being missed a little.

In linux.debian.policy, Thomas Bushnell BSG <tb@becket.net> writes:

> 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."

I would say instead that your package doesn't care whether test is a
builtin or not, but relies on test having a certain set of features.
Wouldn't that be an easier way of phrasing the limitation in policy?

In other words, what about saying something like:

    Any /bin/sh script must work with a minimal POSIX-compliant shell with
    no builtins other than the required ones.  /bin/sh scripts must also
    work with any POSIX-compliant implementations of the following basic
    utilities:  echo, test, (whatever else we want to list).
    Exceptionally, /bin/sh scripts may assume that echo -n works to
    suppress the output of a newline.

    All other basic shell utilities may be assumed to be compatible with
    the binaries provided as part of a base Debian system, meaning that if
    shells implement them as built-ins, they must provide functionality
    equivalent to the standard utilities.

That's very, very rough and will require some rewording, but I hope you
get the idea.

This all came up in the first place, as far as I can tell, because Policy
doesn't draw a clear line between shell behavior and the behavior of
commands that are sometimes built-ins and sometimes not.  So separate the
two cases, by redoing the shell requirement so that it doesn't directly
address optional built-ins, and then explicitly add in those utilities
where a shell can get away with implementing a purely POSIX-compatible
built-in rather than invoking the respective utility.

Please note that I am completely ambivalent on whether test -a and test -o
should be supported.  I just think that if they are allowed, they should
be called out separately just like echo -n is now, and I think the above
wording would accomplish that.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>



Reply to: