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 > (http://www.opengroup.org/onlinepubs/9699919799/utilities/echo.html#tag_20_37_16). > 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 start-stop-daemon. > This means per policy section 3.8 > (http://www.debian.org/doc/debian-policy/ch-binary.html#s3.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 NFS, though. Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739vm3rh0....@turtle.gmx.de
