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

Re: packages being essential but having stuff in /usr/?!

On Thu, 2010-07-15 at 14:59 +0200, Giacomo A. Catenazzi wrote:
> 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.

> 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.
Aggreed.... with the exception that you may have,.. as I noted in my
email just before stuff in initramfs-images which do use such things.

But I'm fully ok with putting this under the responsibility of the
respective author :)

Nevertheless,... I'd like to see definite clarification on this
situation in the policy :)

> '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]
Yes I see also a problem here...

> 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/
Is it really that easy moving such things? I've seen many scripts
throughout debian which hardcode the absolute path (and do not (have to)
set a secure PATH for that reason)... all of them would fail after such

> 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).
Admittedly,... I just noted this, because personally I also like other
non-Linux Unices... and we should not add incompatibilities if
avoidable :)

> 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.
Would be great!... Hopefully also "local" :D

Best wishes,

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: