Quoting Didier Kryn (k...@in2p3.fr): > IIUC, your argument boils down to "depending on /usr for early boot is > a *bug*", while Roger told us why it has become a *feature* (~:
My view, which I expressed in detail prior to Roger joining the thread, is that it's vital to the most vital function of the root filesystem's maintenance software directories (/sbin, /bin, /lib, /lib64) that their binaries function _even_ if /usr is not (or at the moment cannot be) mounted -- because the most vital function of those subtrees is backup, restore, repair, maintenance (functions that might be required to recover/fix /usr). I addressed the main part of Roger's initial post upthread, and don't care to revisit that discussion, except to mention that he dismissed the use-case cited above, which is the traditional Unix use-case, in wording that didn't address the substance of those concerns. > It would certainly be possible to move all applications and dynamic > libraries needed for early boot from the /usr tree to /bin, /sbin and > /lib, but Debian has made a different choice. I'm not 100% sure what you mean by 'early boot' in context of recent discussion about separate /usr. What I'm talking about is maintenance, approximating as mentioned backup, restore, repair, maintenance. It is an integral part of Rick Moen system local policy that those functions must work whether or not /usr is yet present (because they may be called upon to rebuild or recover /usr). If indeed Debian policy differs, to the extent that it differs, then that still doesn't bother me a great deal, since Rick Moen local policy is applied as required to overrule Debian policy. Problem solved. ;-> (This is why I tend not to waste time hyperventilating about dumb distro policy decisions: Submit a bug. If it's rejected or never acted on, just make a local configuration that works around the stupid distro action, and move on to more rewarding parts of life. If moved to public-spiritedness, also publish one's fix a part of a third-party package repo, pro bono public, to help others benefit from your work without needing to replicate ito.) > In the case of NFS, I agree that the only thing to do would be to move > the dynamic library to /lib. Instead, it seems /lib has become a holly > directory where only the libc and the dynamic linker are allowed to > live. That would fix the ldd depency of mount.nfs on /usr/lib contents, yes. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
