On Mon, 22 Apr 2024 at 09:44:12 +0200, Simon Josefsson wrote:
> Philip Hands <p...@hands.com> writes:
> > Might I suggest that the link goes the other way, so that the symlink
> > lives in /usr/bin? That way the existence of the lib directory is
> > somewhat self-documenting.
Having the real executable in /usr/lib(exec) and the symlink in /usr/bin
also makes it possible to be somewhat consistent with packages that don't
normally add themselves to the PATH at all, but could be added to the PATH
by a system integrator, sysadmin or user on specialized systems.
For example flatpak-xdg-utils contains reimplementations of
xdg-email and xdg-open which are probably too limited for use on
ordinary desktop systems, but very suitable for use inside Flatpak,
Toolbx or similar containers. At the moment it installs them into
/usr/libexec/flatpak-xdg-utils/, with nothing in /usr/bin. The
Debian-derived Steam Runtime container environment installs
flatpak-xdg-utils, and also creates non-dpkg-managed symlinks in /usr/bin
pointing to those executables.
(On a normal read/write dpkg system it would not be desirable to create
non-dpkg-managed symlinks in /usr/bin, but in a "write-once" container
image it seems acceptable.)
Adding symlinks like
/usr/bin/flatpak-xdg-open -> ../libexec/flatpak-xdg-utils/xdg-open
seems like a reasonable thing to do, and I might do that in a future version
of flatpak-xdg-utils.
> I'm also not sure where a good path component to store such binaries are,
> libexec or lib? Or share?
To me, this technique seems most in line with how the FHS and GNU Coding
Standards define /usr/libexec.
/usr/share could be used for scripts, but not for native executables,
so we need to choose a location for native executables that are handled
like this (like the ones in flatpak-xdg-utils) in any case; and having
chosen that location, we might as well use that same location for scripts
(in the same way that /usr/bin holds both native executables and scripts)
rather than needing to invent a second path just for scripts.
Older packages use /usr/lib as a substitute for /usr/libexec because the
FHS (and therefore Debian) didn't document /usr/libexec until relatively
recently.
smcv
