Michael Matz schrieb:

On Wed, 26 Apr 2017, Ludwig Nussel wrote:

...

...

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.

As I said, modules (i.e. DSOs that are used with dlopen, not loaded by ld.so) would be placed into (subdirs of) libexec (conceptually (to me) they are more similar to helper executables than shared libraries; they just happen to be implemented via shared library mechanisms)

Shared libraries need to have matching architecures though. Ie 32bit and 64bit libs need different plugins (like e.g. pam modules). So putting them in libexec wouldn't work.

...

...

[...]

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.

Huh? No, whatever the bitness of executable-a (and hence libs used by it), that doesn't at all have to influence the bitness of exe-b execve(2)'ed by it. So, it's _always_ wrong to put executables into lib64

In theory a binary could speak a protocol with it's calling library that differs depending on architecture (like eg. writing structs in shared memory). In such a case it would have to go to lib64.

/usr/lib/perl5 is one of the big blobs with its own way of doing things. Many (but not all) of the files therein are not arch dependend or binary, and hence would actually have a better place under /usr/share. The binary files that are there are not shared libraries for the dynamic loader but dlopen modules, so that would speak for libexec. Splitting the content of perl stuff between /usr/share and /usr/libexec might be seen as to large a hassle (though with the appropriate setting of $PERL5LIB might be invisible in practice), or going against perls idea that there should be "the" main directory for putting stuff in (though even that would be wrong to claim, perl is happy when confired with additional search dirs).

So, considering this I'd answer you with "/usr/libexec/perl5", or "split into /usr/libexec/perl5 and /usr/share/perl5".

Sounds like libexec would lead to even more hairsplitting about where files should be placed for little if any at all practical benefit.

(and I agree with that if libexec isn't used). Nevertheless it happens, and I claim it happens because if a tool has shared libs and helper exes the packager is confused what to place where and just chooses lib64 for everything, and I further claim that with libexec with the appropriate role (or better with lib/lib64 having very strict roles) there would be less confusion. (The rule then would be very easy: every shared lib that's directly shown in output of ldd is put into lib{,64}, and _everything else_ is not put there).

...

On a system without libexec, /usr/lib/%name is the right choice rather than %_libdir/%name.

Yes, agreed as per above. I just randomly looked at gawk for other reasons, et voila, it already gets that part wrong.

It wrongly uses --libexecdir=%{_libdir}. Doesn't matter how we define %_libexecdir then :-)

cu Ludwig