Hi, 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) /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".
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.
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 (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.
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
Yes, so? Those directories also contain shared libraries, and hence it's fine for them to be under lib. Do you mean the discrepancy with my request that lib shall not contain subdirs? To be honest I indeed forgot about these subdirs, but they are an artifact of the ld.so implementation trying to support hardware dependend libs. They never were used much, are hardcoded by ld.so (so that particular set is not extensible) and since the introduction of indirect functions should (and are going to) be replaced by that. So I don't consider them regular subdirs of lib, but rather a funny way of prefixing library names. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org