| 1 |
Upon Danny request, I'll try to summarise here what's going on with |
| 2 |
the /usr/libexec versus /usr/$(get_libdir)/misc thing. |
| 3 |
|
| 4 |
First of all, what is /usr/libexec supposed to contain? Mostly those |
| 5 |
files that are binary executables (or scripts) that should never be |
| 6 |
ran by users directly, not even root; on FreeBSD it contains also |
| 7 |
most of the daemons that are started by rc.d (their init scripts) and |
| 8 |
by cronjobs. |
| 9 |
|
| 10 |
FHS didn't put /usr/libexec in the standard, it instead talks of an |
| 11 |
appropriate subdirectory of the lib directory, which would be the |
| 12 |
above /usr/$(get_libdir)/misc. What's the problem with that? Well, |
| 13 |
CUPS developers shown me the issue first, as I didn't really know |
| 14 |
before they told me about this. |
| 15 |
|
| 16 |
The /usr/libexec/cups directory is currently used to store cups's |
| 17 |
backends, that might be 64- or 32-bit (for instance Canon Pixma's |
| 18 |
backend, being closed source - most of it at least, and available |
| 19 |
only for x86), native or scripted, and so on... they have to be all |
| 20 |
available at the very same directory. |
| 21 |
|
| 22 |
For most of the things /usr/libexec (or /usr/lib/misc) is used or |
| 23 |
should be used for, the ABI for which the executables are is no more |
| 24 |
a problem than /usr/bin executables are built for, as they are called |
| 25 |
through an exec() call, so there should only be one copy of them, of |
| 26 |
the preferred ABI (or of the chosen ABi by the user). |
| 27 |
|
| 28 |
Having /usr/libexec would decouple us from the ABI concern, as the |
| 29 |
directory does not contain any ABI at all; having /usr/$(get_libdir)/ |
| 30 |
misc would allow multiple copies for those rare (and IMHO misdsigned, |
| 31 |
but that's just IMHO) packages that requires different command sets |
| 32 |
depending on the ABI they are built for); having /usr/lib/misc would |
| 33 |
abide to FHS, and mostly decouple us from the ABI topic too. |
| 34 |
|
| 35 |
Another idea Mike (vapier) suggested is to use /usr/$(get_libdir) but |
| 36 |
symlinking the stuff around, so I suppose something like /usr/lib64/ |
| 37 |
misc/cups and /usr/lib32/misc/cups -> ../../lib64/misc/cups . |
| 38 |
|
| 39 |
If we decide on a single way to handle this, we could clean up the |
| 40 |
current mess of different decisions on different packages, and unify |
| 41 |
all of them under a single hierarchy... whatever that is, and thus |
| 42 |
not have the problem of deciding what to do on every ebuild. |
| 43 |
|
| 44 |
-- |
| 45 |
gentoo-dev@g.o mailing list |
Archives