FHS compliance (proposal for LFS)

Erika Pacholleck Pacholleck.E at gmx.de
Wed Aug 9 01:55:22 PDT 2000

Working experience with FHS:
- the 2.1pre was a mess, when 2.1 was released I had rebuild all =:o
- solving contradictions was not possible - no answer
- this seems to be a closed group, individuals not welcome
- and some kind of restricted, if you carefully read the first part
- if a standard is defined and published you have to take it as is

LFS related proposals:
- we should stick to it as long as we need the dirs
- for all empty, useless subdirs (like tmac), just do not create them
- but in /usr/local (as it is a hierarchy on its own) we need them, even empty
- for changes of the real location link them with the FHS dir
- (expl: /usr/share/man (FSH comp) -> /usr/man (real) ) this is allowed
how we end up then:
- we can call it compliant even if some "mandatory" empty ones missing:
- everyone having the FHS structure in his head will know where things are
- dirs not present will then just indicate: not present on this system
- (and not: search for it, the one finding it first has won)

FHS though it is called standard is just a proposal. If we find reasons not
to stick to it (like creating useless empty dirs) we should obey our common
human sense. If this should lead us to FHS not accepting that we are
"fully compliant", ok than we are "compliant" that should be enough.

With view to all those commercial firms transporting (right word?) their pogs
between different platforms which later might need one of those dirs, it is
easy then to just create it (alfs) without breaking anything, and still lfs and
alfs will go with eachother without problems.

Mail archive: http://www.pcrdallas.com/mail-archives/lfs-discuss
IRC access: server: irc.linuxfromscratch.org port: 6667 channel: #LFS
Unsubscribe: email lfs-discuss-request at linuxfromscratch.org and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)

More information about the lfs-dev mailing list