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 <allan@archlinux.org> wrote:
> 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