Upon Danny request, I'll try to summarise here what's going on with
the /usr/libexec versus /usr/$(get_libdir)/misc thing.
First of all, what is /usr/libexec supposed to contain? Mostly those
files that are binary executables (or scripts) that should never be
ran by users directly, not even root; on FreeBSD it contains also
most of the daemons that are started by rc.d (their init scripts) and
by cronjobs.
FHS didn't put /usr/libexec in the standard, it instead talks of an
appropriate subdirectory of the lib directory, which would be the
above /usr/$(get_libdir)/misc. What's the problem with that? Well,
CUPS developers shown me the issue first, as I didn't really know
before they told me about this.
The /usr/libexec/cups directory is currently used to store cups's
backends, that might be 64- or 32-bit (for instance Canon Pixma's
backend, being closed source - most of it at least, and available
only for x86), native or scripted, and so on... they have to be all
available at the very same directory.
For most of the things /usr/libexec (or /usr/lib/misc) is used or
should be used for, the ABI for which the executables are is no more
a problem than /usr/bin executables are built for, as they are called
through an exec() call, so there should only be one copy of them, of
the preferred ABI (or of the chosen ABi by the user).
Having /usr/libexec would decouple us from the ABI concern, as the
directory does not contain any ABI at all; having /usr/$(get_libdir)/
misc would allow multiple copies for those rare (and IMHO misdsigned,
but that's just IMHO) packages that requires different command sets
depending on the ABI they are built for); having /usr/lib/misc would
abide to FHS, and mostly decouple us from the ABI topic too.
Another idea Mike (vapier) suggested is to use /usr/$(get_libdir) but
symlinking the stuff around, so I suppose something like /usr/lib64/
misc/cups and /usr/lib32/misc/cups -> ../../lib64/misc/cups .
If we decide on a single way to handle this, we could clean up the
current mess of different decisions on different packages, and unify
all of them under a single hierarchy... whatever that is, and thus
not have the problem of deciding what to do on every ebuild.
--
[email protected] mailing list
