Lennart Poettering wrote:
> What is the benefit of a separate libexecdir?

The distinction between stuff which belongs into %{_libdir}, which is
different for 32-bit vs. 64-bit, vs. stuff which always goes to the same
place and where only one copy should be installed.

Now it's possible to hardcode /usr/lib (and some stuff notoriously does
this), but IMHO this is all broken. Everything installed by an x86_64 RPM
into /usr/lib is in the wrong place. It should be in /usr/libexec,
/usr/share, /usr/bin or /usr/lib64.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Le 14/06/2011 00:26, Kevin Kofler a écrit :
> Actually, libexec can be interpreted as being a libdir with the multilib
> suffix "exec" (just like "64" is one), which is explicitly allowed by the
> letter of the FHS as written (even if it might be against the spirit).
>
> IMHO, libexec is the one correct place for this stuff.
>
> Kevin Kofler
>
Though i agree that libexec is the right place, i think that
interpretation of FHS is a bit far-fetched.

H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On 06/14/2011 12:26 AM, Kevin Kofler wrote:
> Haïkel Guémar wrote:
>> I spent some time yesterday talking with opensuse guys on irc, since
>> /usr/libexec has not been blessed by FHS
libexecdir is GNU Standards for ages (decades).

It's supposed to be kind of an "auxilliary bindir", to hide away
programs, users are not supposed to execute directly.

It's formal definition[1] is

<cite>
libexecdir

The directory for installing executable programs to be run by other
programs rather than by users. This directory should normally be
‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you
are using Autoconf, write it as ‘@libexecdir@’.)

The definition of ‘libexecdir’ is the same for all packages, so you
should install your data in a subdirectory thereof. Most packages
install their data under ‘$(libexecdir)/package-name/’, possibly within
additional subdirectories thereof, such as
‘$(libexecdir)/package-name/machine/version’.
</cite>

In Fedora, we treat libexecdir as optional and allow packages to install
such "non-user programs" to %libdir/<subdir>/ instead, primarily for
historical reasons.

> Actually, libexec can be interpreted as being a libdir with the multilib
> suffix "exec" (just like "64" is one),
Multilib subdirs are arbitrary directory names. There is no convention
of them being named "lib*".

You might not have tripped over such them on intel based platforms, but
are very common on other architectures/OSes.

Ralf

[1] http://www.gnu.org/prep/standards/standards.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On Mon, 13.06.11 17:41, Miloslav Trma� (mitr@volny.cz) wrote:

>
> On Mon, Jun 13, 2011 at 5:36 PM, Lennart Poettering
> <mzerqung@0pointer.de> wrote:
> > On Mon, 13.06.11 14:27, Matthew Garrett (mjg59@srcf.ucam.org) wrote:
> >> It's a directory for arch-dependent stuff that should only exist once on
> >> a system, whereas lib is for arch-dependent stuff that may exist for
> >> multiple architectures on one system. I have no opinion on whether that
> >> distinction is important.
> >
> > That is not really how it is. /lib is for arch-dependent stuff including
> > the libraries of the primary arch. Libraries for secondary archs are
> > then put in /usr/lib{64,arch}/.
>
> On x86_64 the 64-bit arch is primary and the 32-bit arch is secondary.
> Surely the 32-bit files don't belong to /usr/lib64?
> Mirek

Oh, well, let me clarify this: the executable binaries are actually not
subarch-dependent: i.e. a 32bit process can spawn both 64bit and 32bit
binaries, and a 64bit process can spawn both, too. That means there is
no need to ship both versions of a binary, and while *arch-dependent* an
executable binary is not *subarch-dependent*. That means private
binaries unconditionally belong in /usr/lib, regardless for which
subarch they are compiled and you need only one version of them.

So putting this all together:

"/usr/lib is for arch-dependent stuff, including the libraries of the
primary arch, and all subarch-independent private executable
binaries. Libraries for secondary archs ("subarchs") are then but in
/usr/lib{64,arch}/."

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On Mon, 13.06.11 11:52, Simo Sorce (simo@redhat.com) wrote:

> On Mon, 2011-06-13 at 17:41 +0200, Miloslav Trma� wrote:
> > On Mon, Jun 13, 2011 at 5:36 PM, Lennart Poettering
> > <mzerqung@0pointer.de> wrote:
> > > On Mon, 13.06.11 14:27, Matthew Garrett (mjg59@srcf.ucam.org) wrote:
> > >> It's a directory for arch-dependent stuff that should only exist once on
> > >> a system, whereas lib is for arch-dependent stuff that may exist for
> > >> multiple architectures on one system. I have no opinion on whether that
> > >> distinction is important.
> > >
> > > That is not really how it is. /lib is for arch-dependent stuff including
> > > the libraries of the primary arch. Libraries for secondary archs are
> > > then put in /usr/lib{64,arch}/.
> >
> > On x86_64 the 64-bit arch is primary and the 32-bit arch is secondary.
> > Surely the 32-bit files don't belong to /usr/lib64?
>
> I thinkLennart is saying that on a 64 bit system they would have to go
> to /usr/lib32

No, there is no /usr/lib32.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On Mon, 13.06.11 13:25, Matthew Miller (mattdm@mattdm.org) wrote:

>
> On Mon, Jun 13, 2011 at 05:36:00PM +0200, Lennart Poettering wrote:
> > That is not really how it is. /lib is for arch-dependent stuff including
> > the libraries of the primary arch. Libraries for secondary archs are
> > then put in /usr/lib{64,arch}/.
> >
> > Gentoo is the only distro which is so confused to put binaries that
> > belong into /usr/lib into /usr/lib64 just because they are compiled for
> > 64bit. But that's just because they are confused.
>
> Errr, what?
>
> Fedora has the same "confusion".

No. For example: on Fedora the udev private binaries are in /lib/udev/
(where they belong). Gentoo is confused and puts them in /lib64/udev/
instead (which is broken).

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On Tue, 14.06.11 00:31, Kevin Kofler (kevin.kofler@chello.at) wrote:

>
> Lennart Poettering wrote:
> > What is the benefit of a separate libexecdir?
>
> The distinction between stuff which belongs into %{_libdir}, which is
> different for 32-bit vs. 64-bit, vs. stuff which always goes to the same
> place and where only one copy should be installed.

Well, but in which way is arch-dependent non-executable data any
different from private binaries? I see no reason why one should live in
libdir, and the other in libexecdir.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

2011/6/14 Ralf Corsepius <rc040203@freenet.de>:
> On 06/14/2011 12:26 AM, Kevin Kofler wrote:
>> Haïkel Guémar wrote:
>>> I spent some time yesterday talking with opensuse guys on irc, since
>>> /usr/libexec has not been blessed by FHS
> libexecdir is GNU Standards for ages (decades).
>
> It's supposed to be kind of an "auxilliary bindir", to hide away
> programs, users are not supposed to execute directly.
>
> It's formal definition[1] is
>
> <cite>
> libexecdir
>
> Â* Â* The directory for installing executable programs to be run by other
> programs rather than by users. This directory should normally be
> ‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you
> are using Autoconf, write it as ‘@libexecdir@’.)
>
> Â* Â* The definition of ‘libexecdir’ is the same for all packages, so you
> should install your data in a subdirectory thereof. Most packages
> install their data under ‘$(libexecdir)/package-name/’, possibly within
> additional subdirectories thereof, such as
> ‘$(libexecdir)/package-name/machine/version’.
> </cite>
>
> In Fedora, we treat libexecdir as optional and allow packages to install
> such "non-user programs" to %libdir/<subdir>/ instead, primarily for
> historical reasons.
>
>> Actually, libexec can be interpreted as being a libdir with the multilib
>> suffix "exec" (just like "64" is one),
> Multilib subdirs are arbitrary directory names. There is no convention
> of them being named "lib*".
>
> You might not have tripped over such them on intel based platforms, but
> are very common on other architectures/OSes.
>
> Ralf
>
> [1] http://www.gnu.org/prep/standards/standards.html
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Do we agree that until FHS canonicalize libexecdir, libexecdir is the
recommended location for helper scripts and that /usr/{lib,share} are
*tolerated* (ie: not configurable, requires non-upstream-able
intrusive patch etc ...) ? In consequence, we should then update
packaging guidelines to explicitely state this.

http://bugs.linuxfoundation.org/show_bug.cgi?id=101
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On 06/14/2011 11:57 AM, 80 wrote:
> 2011/6/14 Ralf Corsepius<rc040203@freenet.de>:
>> On 06/14/2011 12:26 AM, Kevin Kofler wrote:
>>> Haïkel Guémar wrote:
>>>> I spent some time yesterday talking with opensuse guys on irc, since
>>>> /usr/libexec has not been blessed by FHS
>> libexecdir is GNU Standards for ages (decades).
>>
>> It's supposed to be kind of an "auxilliary bindir", to hide away
>> programs, users are not supposed to execute directly.
>>
>> It's formal definition[1] is
>>
>> <cite>
>> libexecdir
>>
>> The directory for installing executable programs to be run by other
>> programs rather than by users. This directory should normally be
>> ‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you
>> are using Autoconf, write it as ‘@libexecdir@’.)
>>
>> The definition of ‘libexecdir’ is the same for all packages, so you
>> should install your data in a subdirectory thereof. Most packages
>> install their data under ‘$(libexecdir)/package-name/’, possibly within
>> additional subdirectories thereof, such as
>> ‘$(libexecdir)/package-name/machine/version’.
>> </cite>
>>
>> In Fedora, we treat libexecdir as optional and allow packages to install
>> such "non-user programs" to %libdir/<subdir>/ instead, primarily for
>> historical reasons.

>> [1] http://www.gnu.org/prep/standards/standards.html

> Do we agree that until FHS canonicalize libexecdir, libexecdir is the
> recommended location for helper scripts and that /usr/{lib,share} are
> *tolerated* (ie: not configurable, requires non-upstream-able
> intrusive patch etc ...) ?

Well, I would agree to tolerating /usr/lib/<package>/ (Which btw is the
current defacto rule in Fedora practice) but would disagree otherwise,
because

- /usr/share (aka datadir) is reserved for "arch-independent data", i.e.
should not contain executables and programs.

- /usr/lib (according to the GNU coding standards) should not contain
programs.

- $(libdir)/<package>/ basically is a package's private play-ground and
therefore may also contain programs and scripts.

> In consequence, we should then update
> packaging guidelines to explicitely state this.

<sigh/> some people seem to need written rules for everything, for what
generations of people before them took for granted

Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

2011/6/14 Ralf Corsepius <rc040203@freenet.de>:
>
> Well, I would agree to tolerating /usr/lib/<package>/ (Which btw is the
> current defacto rule in Fedora practice) but would disagree otherwise,
> because
>
> - /usr/share (aka datadir) is reserved for "arch-independent data", i.e.
> should not contain executables and programs.
>
> - /usr/lib (according to the GNU coding standards) should not contain
> programs.
>
> - $(libdir)/<package>/ basically is a package's private play-ground and
> therefore may also contain programs and scripts.
>

ok.

>
> <sigh/> some people seem to need written rules for everything, for what
> generations of people before them took for granted
>
> Ralf
>

We should at least document exceptions to best practices so we can
confine them in a small corner.
"Dark corners are basically fractal — no matter how much you
illuminate, there's always a smaller but darker one." - Brian
Kernighan (one third of the holy *nixy trinity)


H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel