On 05/25/2014 12:26 AM, Bruce Dubbs wrote:
Frans de Boer wrote:
So, looking at the current FHS-document it seems that LFS is mostly in
sync, except for the use of the /usr/lib64 symlink.
The reason that LFS uses the /usr/lib64 symlink is because many packages
assume that they should use /usr/lib64. LFS is not a multilib system,
but many packages make that assumption. For us, everything should go in
/usr/lib (or /lib). The symlinks make that happen.
It would be really nice if the libtool included in many packages didn't
bother to say that the library appears to be moved. That's quite
irritating.
-- Bruce
I known the reason for the current use of symlinks on 64-bit machines,
and as indicated before I don't like it.
However, so many packages are using /lib64 or /usr/lib64 in conformance
to FHS-2.3 chapter 6.1.5, that it will take a long time before those
packages are conformant - to the new FHS (if ever) - again. So, in light
of the draft FHS, directory symlinks might be an accepted interim solution.
Also, standards need to be unambiguous or else they can not serve as a
standard. I will read more about the upcoming FHS and sent them my
thoughts too.
Thanks again, and I will follow the "path" of LFS/BLFS again ;)
Frans.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
