Re: packages being essential but having stuff in /usr/?!
On 2010-07-14 17:36 +0200, Christoph Anton Mitterer wrote:
> I wonder why this never came up before,.. or did it an I'm just blind?
It's been reported as bug #428189 already, but without any followup.
See also #532324.
> I've just read parts of POSIX, where echo is more or less deprecated in
> favour of printf
> Whether users will do this or not is a different question but I've seen
> that Debian/corutils ships echo in /bin, but printf in /usr/bin.
This is indeed a problem if /bin/sh has no printf builtin, but it does
not affect people who use dash or bash.
> The same for many other binaries part of coreutils.
> Now coreutils is marked as essential, right?!
So is dpkg, and it lives almost completely under /usr, except for
> This means per policy section 3.8
> "Essential is defined as the minimal set of functionality that must be
> available and usable on the system at all times"
> As far as I understand,.. it's fully ok, to have /usr on a separate
> (i.e. non-root-) filesystem.
> That however would mean, that even outsite initramfs images (which are
> probably a special case and do not count) many of corutils' binaries are
> not _always_ available.
Before /usr is mounted, yes.
> People would again have to check for them in e.g. their initscripts, or
> basically everything before /usr is mounted, e.g. via NFS.
Only init scripts that do not depend on $remote_fs have to do this check.
> The same might be a problem with other essential packages, too.
I have /usr on a separate partition and did not have any problems in the
last few years with that. Don't know how the situation is with /usr on