Mailinglist Archive: opensuse-packaging (102 mails)

< Previous Next >
Re: [opensuse-packaging] Proposal: Update rpm configuration to fix issues and rationalize configuration
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >