On 29-12-16 00:00, Russ Allbery wrote:
Frans de Boer <[email protected]> writes:
Of course I know that those systems can support multiple bit sizes, but
the FHS 3.0 leaves this all open. Nowhere it is stated that machines
with only a single bit size should have only /lib, the may have (or not)
a qualifier tagged to it. If I chose to have only 64-bit libraries on my
amd64, I am free to only use library directories without qualifier.
That said, I can appreciate also the idea that on hardware capable of
handling multiple architectures - read size of data paths - you always use
qualifiers, regardless if only one or multiple library directories are
used.
I'm not sure if you're familiar with how Debian approached this, but I
personally consider it generally superior to the lib32/lib64 approach
since it allows for arbitrary different ABIs with separate libraries and
avoids making any assumptions about the distinctions between them.
In Debian and Debian-derived multiarch systems, all multiarch-aware
libraries are moved out of /lib and /usr/lib into, e.g.,
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
In other words, an architecture string is appended, and those directories
are then added to the dynamic linker search path. For the typical i386
and x86_64 cases, one has /usr/lib/i386-linux-gnu and
/usr/lib/x86_64-linux-gnu directories. But this generalizes to any number
of architectures, and also usefully generalizes to a directory location
for cross-compilers and similar tools. (In other words, nothing
constrains those directories to only be for architectures whose binaries
are runnable on the local system.)
If it where a fresh start of emerging unix/linux distributions the above
structure would make sense. However, looking at the various (core)
packages, most of them adhere to the notion of
[/usr[/local]]/lib<qualifier>. I suspect that changing that code as well
as the mindset of the maintainers would take a long time.
As soon as Fedora and Debian maintainers come to a workable and
consistent agreement, we all might to adapt to the new situation. I
don't want to get involved in this already decade long discussion,
simply because both sides are right and to some degree wrong.
So, in the meantime it is better to make FHS consistent to what is
currently the most used schema. Any future transition is...well a future
transition.
--- Frans.
_______________________________________________
fhs-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/fhs-discuss
