64-bit binaries in /usr/lib

[Elan Ruusamäe]

On 09.10.2016 15:08, Adam Osuchowski wrote:
> Elan Ruusamäe wrote:
>> every package probably has reason, given examples it would be easier to
>> explain.
> $ rpm -qf `find {/usr,}/lib -type f -perm -0100 | xargs file | grep 'ELF 64-bit LSB executable' | cut -f1 -d:` | sort -u
> ConsoleKit-0.4.6-3.x86_64
> cups-filters-1.8.3-3.x86_64
> git-core-2.10.0-1.x86_64
> git-core-svn-2.10.0-1.x86_64
> libinput-1.4.1-1.x86_64
> nagios-plugin-check_load-2.1.3-1.x86_64
> nagios-plugins-2.1.3-1.x86_64
> polkit-0.113-3.x86_64
> rpm-5.4.15-37.x86_64
> rpm-build-5.4.15-37.x86_64
> rpm-utils-5.4.15-37.x86_64
> sysstat-11.2.0-3.x86_64
> udisks-1.0.5-3.x86_64
>
> In particular, git-core kept its binaries in /usr/lib64 formerly but it
> was changed to /usr/lib.

it's in changelog, to allow adding programs to git-core dir without 
forcing them to be "arch" packages, ie git-core-slug is itself noarch.

>   nagios-common contains both of them:
>
> $ rpm -qf /usr/lib{,64}/nagios/plugins
> nagios-common-4.0.8-5.x86_64
> nagios-common-4.0.8-5.x86_64

the same reason: to allow libexec dir to be noarch to allow noarch packages.
and the lib64 is kept for compatibility.


> cups and rpm keep /usr/lib all the time.
those are upstream decisions, but likely due same reasons as above two 
pld packagings.

>
>> it may be deliberately packaged like this in pld, or just because
>> upstream uses such packaging (and it's not "fixed" in pld)
> It is rather PLD issue.

1:1 so far with given examples, it's even!

>
>> but the (--libdir) /usr/lib vs /usr/lib64 (and /usr/libx32) are for
>> libraries (libfoo.so.1), so you could parallel install libfoo.so.1(ix84)
>> and libfoo.so.1(x86-64).
> That is, shared libraries on x86-64 arch should be placed in {/usr,}/lib64
> and binaries (not intended to run directly by user), scripts and other
> private package files in {/usr,}/lib. Do I understand it correctly?

pld has not standardized this to my knowledge. and i haven't read FHS 
part which pld tries to follow.
>> there's also --libexecdir which is %{_libdir} in pld, but
>> %{_prefix}/libexec in other distros, and that path is used to provide
>> private binaries for application (not intended to be used from $PATH), that
>> is the most common case how binaries end up in /usr/lib* trees.
>>
>> i personally also think --libexecdir should be %{_prefix}/libexec. it would
>> make configurations simpler, don't need to patch for %{_libdir} everywhere.
> I know but now it is totally removed and no package use it:
>
> # ipoldek 'search -f /usr/libexec/*'
> Loading [pndir]th...
> Loading [pndir]th...
> 26078 packages read
> Loading [rpmdbcache]/var/lib/rpm...
> 3352 packages loaded
> Searching packages..........................................done.
> No package matches '/usr/libexec/*'

that is because %{_libexecdir} is defined as %{_libdir} in pld, and that 
gets passed so to configure --libexecdir argument so the applications 
using @libexecdir@ get their files placed to %{_libdir}

some programs even have had issues with this because they want to place 
%{_libexecdir}/%{name} as directory and %{_libdir}/%{name} as executable
which would both end up with /usr/lib64/mate-settings-daemon
> Besides, FSB admits of using /usr/lib insted of /usr/libexec.
FSB? you mean LSB? FHS?


-- 
glen