Frans de Boer wrote:
On 22-03-17 16:51, Bruce Dubbs wrote:
Frans de Boer wrote:
LS,
The FHS is now with us for some considerable long time, but what has been
it's impact?
It has caused controversy between Debian versus Fedora followers, which
has lead to some mutual understanding about the naming of their library
directories.
However, the old school of using [/usr[/local]]/lib is still upon us.
Many
tools needed to create a basic tool chain (GNU, Non-GNU, Perl, Python,
Kernel etc.) still have hard coded paths to [...]/lib. FHS allows an
alternative of [...]/lib<qualifier>, whereby [...]/lib CAN be an optional
link to that directory. This, however, is still not the standard given
the
many hard coded paths.
Example, if I want to make a system which uses [...]/lib64, I still
end-up
with having either a separate directory named [...]/lib, or it is a link
to the lib64 directory.
Now if I want to make - for what ever reason - directories containing
32-bit libraries named [...]/lib32, I still end up with 64-bit libraries
being overwritten by 32-bit libraries because of these hard coded paths.
So, what is the use of the FHS guidelines if many people just keep on
living in their 32-bit past and force their heritage upon us?
I can automatically scan every piece of code and change the [...]/lib
directives into some architecture dependent contents - including man/info
pages - and can tell that this approach is working, but is also CPU time
consuming. I also may introduce errors which show them self in a future
situation only.
So, again, what is the use of the FHS if so many developers just
ignore it?
FHS is very useful so that everyone does not go out an design their own
directory hierarchy. You pick on one problem, lib vs lib<qual>, as if
that is the problem of FHS. The real problem is a relatively small set
of proprietary packages that are not available as source that do not
provide separate 32-bit and 64-bit binaries. If we had source or
appropriate libraries for the target architecture, then everything would
be in lib and your issue would not exist.
I'll note that we seem to get along quite well with no lib<qual> at all.
You seem to want to throw out the whole thing because of one problem not
under the control of the standard.
-- Bruce Dubbs
linuxfromscratch.org
Can you point the part where I suggest to throw out the whole "thing"? I
guess that's your interpretation.
You do say above "So, again, what is the use of the FHS..."
The thing is that when you want 32- and 64-bit libraries in one system,
you might overwrite 64-bit libraries residing under [...]/lib. The LFS
approach is just use [...]/lib and the rest are soft links. Which works
for either a single 32-bit or 64-bit approach, not both. It works, sure.
But is it a clean way?
Actually we have done away with the */lib64 -> */lib symlinks. We only
have */lib now with the exception of /lib64 which is a regular directory
with the total contents of two symlinks to accommodate glibc.
As for your other objection, yes there are binaries which adhere to a
standard they seem fit. But given the fact that most software under Linux
is available in source, I - personally - could not care less about those
packages. I focus on the question why so many core packages still have
hard-coded paths?
I agree with that, but I think that is this is the wrong forum.
-- Bruce
_______________________________________________
fhs-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/fhs-discuss
