Re: packages being essential but having stuff in /usr/?!
On 15.07.2010 14:31, Christoph Anton Mitterer wrote:
On Thu, 2010-07-15 at 12:09 +0200, Giacomo A. Catenazzi wrote:
System initialisation and in general system script are outside POSIX
scope, as well many common command executed by such scripts
(administration tools are also outside POSIX).
Well yes,... nevertheless I guess that it's always a good idea to
restrict to scripts to the bare minimum... of course as far as possible.
Yes, and usually it is so. In a short period the maintainer will
receive bug report about non working init.d script with some
configuration, which force people to minimize the init scripts.
Additionally system initialisation is very complex and it should handle
to many different setups (from no local disks to very complex local
disks setup, etc.).
That's what I've meant... and with such complex setups, not having many
coreutils available could be a problem.
usually no. see below.
Our "boot people" take care about init scripts, their requirements
and thus what it should be moved from /usr to root.
It is a case-by-case analysis.
Uhm... looking at coreutils, I find many programs which I guess can be
used (or are actually) during system initialisation, e.g.:
env
base64
dirname
[
test
stat
timeout
id
printf
just to name a few.
Early init script doesn't need a lot of complexity, and
they are must pretty stupid, so they usually don't need some
commands of coreutils.
e.g. 'stat' and 'id' are not so usefull at such stage,
the script could assume root and basic root files available.
'env' also not is very usefull: easy to work around with
standard shell. The other standard use of 'env' is '#!/usr/bin/env"
so an already hard coded path.
'dirname', '[' and 'test' could cause some problem. Usually they are
build-in on shell, but it is not mandatory, and policy BTW mandate
some extended (from POSIX) syntax on built-in 'test', but I think
policy missed the case of 'test' not being built-in and not
being available (because it is in /usr/bin).
[this is IMHO a BUG in policy]
timout could be interesting, but when a init.d script will
need it, I think there will be no problem to more it in /bin/
not portable? Do you have some real/widely used examples of
incompatible use?
Especially "-n",... which is widely used,... but not portable.
Yes, but it is very difficult (maybe impossible) to see a real
script where echo -n is intentionally intended to write -n (at
beginning of a line).
BTW GNU/Linux is not fully POSIX compatible by design. It follow the
LSB (an other standard) and there is a ISO groups to find and try
to correct the differences. "echo" is one of "required" difference.
Yeah I know,... but it does not automatically mean that this were the "right" choice.
I guess LSB&Co. just made it because it was already so widely used, that
you could never convince people to do different.
But I think now echo -n must be supported by all systems (not only on
LSB systems), because of wide usage.
POSIX successfully standardized a lot of things, but POSIX also failed
on few points ('echo -n' and 'pax'), and IMHO it is a lost campain.
I expect that in next posix the 'echo -n' and 'tar' will reach the
normative status.
ciao
cate
Reply to: