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

Re: RFD: Essential packages, /, and /usr



> 	Codify what, please? I personally use which, since it is
>  provided by am essential package, and I can live with it eing an
>  external program, and missing aliases. People can also use POSIX type

You don't have that with zsh, since which is a builtin.

>  (umm, does zsh have type?). Why does this have to be codified? When

zsh has type as a builtin, though it isn't POSIX either.

>  do we want to stop codifying every little thing? 

When there are no more problems?  There are numerous #!/bin/sh scripts
in Debian that are not POSIX-compliant.  One might get the idea, if one
were to read Debian's policy documents, that these scripts violate
Policy.  One might also get the idea, if one were to read the same
section, that one could install a POSIX-compliant shell as /bin/sh on
one's Debian system, and that one would experience no difficulties in
doing so.  Of course, this is a fallacy.

What is the "common sense" thing to do?  I would say that it's to have
bash as /bin/sh, since that's what most maintainers are using, and
that's what's most likely to work with the most scripts.

I, on the other hand, would rather have ash as /bin/sh.  What makes this
possible?  That policy has codified the requirement for /bin/sh scripts
to be POSIX-compliant, and ash, for the most part, does a good job
executing POSIX-compliant scripts.  If this were not codified, and we
were still living in the dark ages when someone would be lynched for
using ash as /bin/sh and having the gall to expect sympathy, then well,
lynching would be the least of problems.

> 	I would possibly classify hard coded paths a bug in the
>  package, since I may well be experimenting with PATH's. But hard
>  coding paths is just asking for breakage, in case the FHS or the LSB
>  or someone decrees the binary move. Since there is no need for such
>  hard coded paths, doing so is bad design.

And not doing so invites unexpected behaviors.


-- 
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: