Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Roger Leigh <rleigh@codelibre.net> writes:
> On Wed, Dec 14, 2011 at 12:53:24PM -0500, Zachary Harris wrote:
>> I could be wrong, but my (admittedly stereotyped) impression of the
>> standard use cases is that if you've got someone who DOES want to mount
>> /usr separately from "/" (e.g. over NFS or because of a selectively
>> encrypted LVM), such person is more likely wanting to do so in "pure
>> Debian", rather than, say, in Ubuntu.
>
> This is a bit beside the point. People keep bringing up mounting /usr
> over NFS. No one to date has provided a sensible use case for it.
> This is because "old timers" (or whoever) have failed to notice a
> fundamental flaw: *package management does not work with a shared /usr*.
The cluster setup I use at work uses an initramfs with all the essential
stuff in it and mounts the rest over NFS. The reason why this works is
that the / is just as shared as /usr. Just one is shared via pxe and
then other via NFS.
The reason for not having everything on NFS is to reduce network load
and that nodes should be minimally functional without NFS. Esspecially
that you can still log in as root and diagnose problems.
> On a Debian there are really only two categories for partitions:
> those under the control of the package manager, and those which
> are not (user data etc.). Does it make sense to split package-managed
> files over multiple partitions? (other than /var)
>
> This is *the* key point. Under a package managed distribution /
> and /usr are part of a *managed whole*. They can't exist separately,
> even if they are on different partitions, mounted over NFS, or
> whatever. It's fine that such things /work/, but we do need to
> question /why/ one would do such a thing. If you're mounting /usr
> over NFS, the real question is "why aren't you mounting / over NFS,
> which also then includes /usr?". Mounting /usr separately makes no
> sense *at all*.
>
> The same argument applies to encryption. / and /usr both contain a
> selection of programs, libraries etc. If you're encrypting one, why
> would you not encrypt all of it? And the same for mounting read-only.
/, specifically /etc, contains sensitive information so it has to be
encrypted. /usr on the other hand does not and encrypting it is just a
waste of cpu time.
This would actually call for having /etc a seperate (encrypted)
partition and /usr not. Encrypting /bin or /lib is indeed as useless as
/usr.
> The question that needs answering is this:
>
> "what are the reasons, today, for a separate /usr?"
>
> Excluding "historical practice". What real function does it have?
> Does it have any reason to continue to exist?
>
> And regarding the LSB: I checked, and it would be entirely compliant
> for Debian to merge the two.
>
>> Enforce a
>> policy that anything being put into /sbin or /bin must pass the "ldd
>> test". If a dependency is in /usr/lib then negotiations have to be made
>> to reach an agreement to either "downgrade" the binary to /usr/{s,}bin
>> or "upgrade" the library to /lib. (In the case of downgrading the
>> binary, you can say that the user of the Debian package bears the
>> responsibility to have ensured that the executables he personally
>> considers "essential" in his own context were accessible where he would
>> need them when he would need them. But the distro itself should take
>> responsibility for being CONSISTENT, and thus should not say, "Here's
>> something available to you in /sbin---oh, but you can't actually use it
>> from there (so to speak).")
>
> The problem here is, can we /be/ consistent? What is one system's
> essential package required for bringing up a working system is
> someone else's occasionally-used tool that's not important at all.
> Yet both might be required to be on the rootfs. We can't be all
> things to all people in the current state. But unification /would/
> *guarantee* things would always work and be consistent: every
> program and library would always be right there on the rootfs.
You are not reading him.
consistent == if it is in /sbin or /bin then it works without /usr.
consistent != everything even some insane user might want in / is in /.
That was exactly his point.
> The status quo is a "best effort". Things sometimes break, and
> there's an continuing migration of "essential" packages to the
> rootfs. Given that a modern initramfs can mount pretty much any
> filesystem, either locally or over a network, what's the *real*
> reason for a separate /usr? It's certainly not for any booting-
> related reason.
MfG
Goswin
Reply to: