Gentoo Archives: gentoo-dev

From: "Diego Pettenò" <flameeyes@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Reasoning for unifying libexec and lib/misc directories
Date: Thu, 14 Dec 2006 22:17:35
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.

gentoo-dev@g.o mailing list