Mailinglist Archive: opensuse-packaging (102 mails)

< Previous Next >
Re: [opensuse-packaging] Proposal: Update rpm configuration to fix issues and rationalize configuration
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

--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >