[Fedora-packaging] The role of %{_libexecdir} for using environment-modules

Denis Leroy denis at poolshark.org
Wed Oct 8 15:15:59 UTC 2008

Rex Dieter wrote:
> Dominik 'Rathann' Mierzejewski wrote:
>> On Wednesday, 08 October 2008 at 15:28, Ed Hill wrote:
>>>   /usr/libexec/%{name}
>>>   /usr/libexec/%{name}-%{version}
>>> that allows both names and, if desired, versions.
>> It still feels like a bit of an abuse of libexec.
>> I prefer using %{_libdir}/%{name}(-%{version})/bin for this purpose.
> Agreed.  As had been pointed out already, libexec is for private stuff, 
> not exposed to the end-user.

Agreed also.

> Also, while I'm not familiar with the app, it still feels odd to ship > 
> 1 version, and should be avoided if reasonably possible.

Yes I have a problem with that too. There are very few "leaf" (i.e. 
non-libs) packages that have multiple installable concurrent versions. 
gcc is an example,  For compat-gcc-XXX, the "public" executables live in 
/usr/bin but have a version suffix added (i.e. "/usr/bin/gcc34"), while 
the "private" executables live in a versioned directory under 
/usr/libexec, and that path is hardcoded into the compat-gcc build.

so there are 2 issues to discuss here:

1) multiple concurrent versions installed. Is that really necessary ? Is 
it a question of binary data compatibility, or a whole set of features 
that were removed by the new version ?

2) where to put the binaries. Gromacs seems to have 50+ executables 
(what's the exact number?). Most have non-trivial names with a "g_" 
prefix, a few are more conflict-prone, namely "wheel", "highway" or 

More information about the Fedora-packaging mailing list