-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've kept out of this for as long as I could, but I think it's time
to put my two cents in...
On 2011-04-17, at 01:55, Simon Geard wrote:
> On Sat, 2011-04-16 at 13:29 -0500, DJ Lucas wrote:
>> On 04/13/2011 09:04 PM, Mike McCarty wrote:
>>> There is an incompatibility with using udev and /usr being a
>>> separate file system, which users of LFS need to be aware of.
>>> It is presently not possible, in general, to use udev and have
>>> /usr be a separately mounted file system. This is something to
>>> consider when planning the layout of the disc drives. The current
>>> implementation of udev is incompatible with the File System
>>> Hierarchy
>>> Standard.
>>
>> This is incorrect. udev is perfectly FHS compliant as installed in
>> LFS
>> and provides only minimal challenges to make it so in BLFS.
[ snip ]
>
> My understanding is that the problem isn't with the location of
> libraries - it's with the location of data under /usr/share. Stuff
> like
> the pci.ids and usb.ids files, which are apparently required for
> some of
> the udev rules. Those files could presumably be moved to somewhere
> under /, but there's no obvious place to put them, no /share
> directory...
SHORT VERSION (for the "tl;dr" crowd):
- Good idea, very bad implementation
- Mount to /usr/remote
- Set PATH=/usr/remote:/usr:/usr/local
- FHS is broken; break FHS
- ...and if the 'tubes are busted?
LONG VERSION (for those who have the time for long-winded rationale):
Despite the implication that /usr/local is for binaries and
libraries and so forth that are installed for the local computer
only, the fact that /usr/local is a subdirectory of /usr implies
that /usr/local will also be on the networked server. After all,
won't the NFS server have its own /usr/local?
When you call a binary or library stored in /usr/local/... well,
whose is it? Is it the local /usr/local's or the remote /usr/
local's? And if you think a local /local and a remote /local is
confusing enough, just imagine what happens when you try it to update
the local /usr/local with the contents of the remote /usr/local:
"cp: /usr/local and /usr/local are identical (not copied)."
As for FHS, it does not address the issue directly because FHS was
addressing the userbase's single machines. And, with respect to the
suggestion that the [B|C]LFS community should follow the lead of the
Big Distros, **** no: this is ground they won't cover because they're
too busy appeasing and growing their single-user userbase. Consider
this: rpm, apt-get, yum, and all their incompatible kin exist because
Red Hat/Fedora, Debian/Ubuntu, SuSE, & co. did what was convenient
for themselves, and not necessarily what's best for all Linuxes at
large and equally.
Well... not until FHS twists their arms, that is; and as I've said,
FHS says nothing.
So... off-the-shelf distros won't serve the expressed intended
purpose (unless you count Plan 9 as a distro, in which case the
answer is still a "maybe" at best); networked filesystem path
logistics are beyond the scope of FHS's jurisdiction; and (at last
check) LSB has nothing to say on the subject.
Y'know what? When no rule applies, I make one up. Here goes:
It stands to reason that if there's a local version of /usr, then
all things being equal and opposite, there ought to be a remote
version /usr. This gives you three locations in total:
- /usr, which is the stock /usr populated by Big Distros and [B|C]LFS
- /usr/local, which contains machine-specific binaries and libraries
- and /usr/remote, which contains the network-/office-/collective-
specific binaries and libraries
Once you have these set up, all that's left to do is to amend PATH
accordingly. What order you choose depends on how you interpret OSI
Layer 8 (or 8 & 9, or 8 & 9 & 10), but all in all this naïve solution
has a precedent: if FHS insists on /usr/local, then FHS has no right
to complain about /usr/remote.
I'd ask what your fallback is in case the network goes down, but I
think I've said far more than 2¢'s worth. We now return you to your
regularly-scheduled debate...
______ ______
\_(_)_\ /_(_)_/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAk2qctsACgkQUm23fyiLpft5TwCfUCrwGb09ftnnqK96bLPrB9vW
V7gAoIIWI3h2MEEpdens4jQJFjpZXcmT
=C5Yl
-----END PGP SIGNATURE-----
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
