[lfs-support] New directory layout and FHS 3.0
Frans de Boer
frans at fransdb.nl
Tue Dec 20 13:34:44 PST 2016
On 20-12-16 21:56, Bruce Dubbs wrote:
> Frans de Boer wrote:
>> Hi all,
>> I just noticed that there are changes in the development version of LFS,
>> related to x86_64 architecture. But i do miss the rationale and/or more
>> explanation. The latter is important because I see several changes which
>> make sense, but misses other related changes in various other packages.
>> Also having now /lib64 as a directory instead of a link puzzles me. The
>> more because /lib is still a directory and not a link to /lib64 as per
> Where does FHS 3.0 say a symlink is required?
> What additional explanation would you suggest and where should it be?
>> Looking at the FHS 3.0 documentation does not help either since the new
>> LFS directory structure seems to be a non-consistent mix of various
>> possibilities. See above and next example: /usr/lib with redundant link
> 4.8. /usr/lib<qual> : Alternate format libraries (optional)
> does not seem to require /usr/lib64.
> -- Bruce
Footnote 13 makes an implicit reference to it. But I admit, it's not a
very strong point.
However, it seems not consistent to have /usr/lib and in the root
/lib64. Use of qualifiers is - as I read it - only meant to be use by
multi-library systems, which LFS explicitly states currently that it is not.
Also, I never implied that having /lib64 does require /usr/lib64 -
simply because there is no hard relation between them or their content.
It's just what I stated above, inconsistent use of qualifiers.
By the way: Having /lib64 and /usr/lib64 as links to their respective
lib directory make sense only when using third party (binary) packages.
Finally on the matter of explanation: sure, I can write one and find a
place to put it up. But we first need to get into the "inconsistency"
issue to be able to make a coherent and justifiable explanation.
More information about the lfs-support