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
_______________________________________________
pld-devel-en mailing list
[email protected]
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
