Incorrect order of /usr/bin and /usr/sbin in path

[Kalev Lember]

On 05/06/2014 12:25 AM, Toshio Kuratomi wrote:
> <snip>
> %{_libexecdir} and %{_libdir}/$pkg are both valid in the packaging
> guidelines.

Yep, and both valid variants differ from what other distros use. Debian
uses /usr/lib/$pkg for @libexecdir at .


> <snip>

> If upstream is using the autotools you should just use @pkglibexecdir@ or
> @libexecdir at .  Linux distributions, BSDs and etc all set --libexecdir to
> the proper location for their tastes.

I agree with you here. As long as the helpers are only used internally,
it's indeed very simple. It doesn't matter what it exactly expands to:
the app can always find its own files since it can easily keep track how
it was configured.

But there is another class of packages that provide system wide
services. Those packages install system wide helpers and expect _other_
programs to run these.

At that point, the location of /usr/libexec/ vs /usr/lib/$pkg/ vs
/usr/$lib/$pkg becomes the interface that other programs are supposed to
use. And when those differ between different distros, it becomes
difficult for _consumers_ to know where they are installed.

This is why systemd insists on using /usr/lib/systemd on all distros so
that it would be consistent for consumers.

(I wrote a long text here how I ran into this issue having to detect
/usr/libexec/pk-trigger-offline-update (Fedora) vs
/usr/lib/packagekit/pk-trigger-offline-update (Debian), but decided to
delete it since it seemed too specialized.)


> If upstream does not use autotools then they may end up having to do
> a platform check for helper_dir.  But they could also end up having to do
> a platform check for shared libraries or arch-specific data files. The
> difference between Fedora and other distros is really multilib, not libexec.

No, I disagree, those are separate issues.

Using /usr/lib/$pkg for helper binaries is no more or no less multilib
compatible than /usr/libexec. Neither one supports parallel installation
of executables.


>> Relaxing the guidelines would allow those upstreams to write saner code,
>> and be more compatible across various distributions.
> 
> If we get rid of multilib then that would be fine otherwise it'll be more
> error prone to add %{_prefix}/lib into the mix with  %{_libexecdir} and
> %{_libdir}.  Most upstreams do not know about or care about multilib.  This
> means that they mix stuff appropriate for %{_prefix}/lib/$pkg in with things
> that must go in %{_libdir}/$pkg.

Yes, that's a fair point. More options makes it easier for packagers to
mess up in some way. I guess that's also why some people here are
advocating for complete removal of /usr/libexec to reduce the number of
options.

-- 
Kalev