[arch-dev-public] Libexec policy?
I've been wondering why we do not have /usr/libexec. The GNOME packages apparently use --libexecdir=/usr/lib/$pkgname. We've been running into problems with GNOME 3.2 because increasingly more components depend on the libexecdir being the same across all packages (we already had this problem in GDM, where we currently patch). The other option, used by a few other packages, seems to be using --libexecdir=/usr/lib, which seems the next best solution to me. That is, if /usr/libexec is not available. Comments?
On 03.09.2011 10:05, Jan Steffens wrote:
I've been wondering why we do not have /usr/libexec.
I think we don't have /usr/libexec because it's not in FHS [1].
The GNOME packages apparently use --libexecdir=/usr/lib/$pkgname. We've been running into problems with GNOME 3.2 because increasingly more components depend on the libexecdir being the same across all packages (we already had this problem in GDM, where we currently patch).
The other option, used by a few other packages, seems to be using --libexecdir=/usr/lib, which seems the next best solution to me. That is, if /usr/libexec is not available.
If possible, try to stick to FHS and move application specific stuff into subdirectories (/usr/lib/$pkgname or if that doesn't work for gnome maybe /usr/lib/gnome). If none of this works I guess it's okay to use /usr/lib directly. [1] http://proton.pathname.com/fhs/ -- Florian Pritz
On 03/09/11 18:05, Jan Steffens wrote:
I've been wondering why we do not have /usr/libexec.
The GNOME packages apparently use --libexecdir=/usr/lib/$pkgname. We've been running into problems with GNOME 3.2 because increasingly more components depend on the libexecdir being the same across all packages (we already had this problem in GDM, where we currently patch).
The other option, used by a few other packages, seems to be using --libexecdir=/usr/lib, which seems the next best solution to me. That is, if /usr/libexec is not available.
Comments?
I think the general reason is that the libexec directory is not specified in the FHS. Have not looked at the latest draft though... Importantly, /usr/lib/ is not excluded from having binaries. "/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts." As far as --libexecdir=/usr/lib vs /usr/lib/$pkgname, I think that really depends how much is being shoved in /usr/lib. Could you use /usr/lib/gnome? Allan
On Sat, Sep 3, 2011 at 10:35 AM, Allan McRae
On 03/09/11 18:05, Jan Steffens wrote:
I've been wondering why we do not have /usr/libexec.
I think the general reason is that the libexec directory is not specified in the FHS. Have not looked at the latest draft though...
If I understand correctly the reason libexec is not in FHS is that the line between what is a library and what is an internal binary is not necessarily clear in all cases, and making the distinction does not really give you any benefits even when you can make it. I'd vote for /usr/lib/gnome if /usr/lib/$pkgname is causing problems. Cheers, Tom
participants (4)
-
Allan McRae
-
Florian Pritz
-
Jan Steffens
-
Tom Gundersen