Michael Matz schrieb:

On Wed, 26 Apr 2017, Ludwig Nussel wrote:

...

...

...

What's wrong with /usr/lib/name/?

Everything. lib shall not contain executables. lib shall not contain subdirectories. lib shall contain only libraries. lib shall contain _nothing_ on lib64 platforms.

A pretty radical demand. I guess you have technical insight that makes you say that?

It's not so much technical, but as I said there are also no technical reasons why e.g. /usr/include would be separate, all its content could just as well be stuffed into /usr/lib. It's about what conceptually

/usr/include is rather special as it's really only for C. All others have to live with a subdir in /usr/share or - /usr/lib.

belongs where, header files to /usr/include, libraries to /usr/lib and executables called only internally by other tools into /usr/libexec, or /usr/libexec/$toolname (modules would belong into this category) and other files associated with a tool into /usr/share.

From there it follows fairly easily that /usr/lib should be empty on a pure lib64 system. Also /usr/lib should be able to be mounted noexec, and

So where would you move /usr/lib/perl5 then? I has it's own architecture specific subdirectories. And where to put plugins in general? They ought to be in subdirectories of lib to not interfere with the dynamic linker.

everything should continue to work. One advantage of putting executable helpers for a tool into libexec, not lib{,64} would be that the path doesn't depend on architecture bits (as it should be, because for executables the bitness doesn't matter, for libraries it does).

Packages that put helper binaries in lib64 are doing it wrong unless the binary has an ABI incompatible with a 32bit library that calls it. On a system without libexec, /usr/lib/%name is the right choice rather than %_libdir/%name.

...

Even the dynamic linker may read libraries from subdirectories.

Only if configured in /etc/ld.so.conf or LD_LIBRARY_PATH.

It looks into e.g. tls and x86_64 subdirectories on x86_64

cu Ludwig