FHS-thoughts
Reading File Hierarchy Standard (FHS) version 2.3 leaves a double
feeling regarding their standardization effort. Especially around the
subject of lib versus lib64 or lib32. In the documentation lib64 and
lib32 are indicated as alternative names indicating that the contents
contains either 64- or 32-bit libraries. Thereby implicitly stating that
lib contains the default machine libraries.
Then, near the end of the document – chapter 6.1.5 –, the statement is
made about various architectures and pointing out that AMD64 and thus
also EM64T systems must use the lib64 for their default system libraries
and that 32-bit libraries must reside in lib. The rational used was that
many 32-bit programs expect their libraries still in /usr/lib. Then
again, that was in 2004.
Not using 32-bit libraries allows – as per 4.8.1 footnote 6 – the lib
directory to be pointed (symlink) to the lib64 directory.
Thus, FHS-2.3 is in conflict with itself because of the added chapter
6.1.5 and as such cannot be regarded as a robust standard.
Overview of used layouts:
1. There are packages that regard lib as the default for 32-bit
libraries and libraries who are not dependent on an architecture. These
use lib64 for all 64-libraries only.
2. There are packages that use lib for architecture independent only
libraries, lib32 and lib64 for architectural dependent libraries.
3. There are solutions which use lib for all system libraries and have
lib64 or lib32 point to that directory. This construct is only used in
cases where the whole system has only one type of libraries and cannot
easily be used in a multi-lib environment.
4. And last but not least, there are those who have the same as the
second option, but only to point (symlink) lib to the directory
containing the default system libraries.
I personally would like to see option 2 as being the standard because it
makes the most sense. It follows the current (2.3 version) of the FHS
with the exception of lib32 for modern day 32-bit libraries.
Option 1 can be chosen for systems accommodating out-dated 32-bit
packages. Mostly because these packages are hard-wired to use lib
instead of allowing some flexibility.
The third case is used in LFS and mono architecture derivatives. This is
easy, but does not follow the FHS guidelines as indicated above for
AMD64/EM64T systems.
Option 4 would be my second choice with the notion that all
architectural independent libraries should be in only one – preferably
the systems default – of the architectural dependent directories.
Conclusion
LFS is only intended for use on x86 systems with either a 32-bit or
64-bit architecture. At some point in the past, it was decided that the
same layout would be used om AMD64/EM64T systems as with the previous
32-bit only systems. I can guess why, but the result is that it is no
longer FHS-2.3 compliant anymore.
Since FHS-2.3 is not maintained anymore – the last known publication was
in 2004 – it can no longer be regarded as the principle guide for
directory layouts on *nix systems.
Above I have indicated a few options for an updated layout in regard to
naming directories for system libraries. As said, I personally like the
second option as it offers a clean view of the system and allows for
having mono- or multi-lib systems without to much hassle.
I invite all to react on the above suggestions.
Frans.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
