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

[Toshio Kuratomi]

Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 08 October 2008 at 20:59, Toshio Kuratomi wrote:
>> Rex Dieter wrote:
>>> Ed Hill wrote:
>>>
>>>> If you use %{_libdir} then you will have to deal with multi-lib 
>>> What makes you say that?
>>>
>> As Ralf said, when you place binaries into %{_libdir} you have to deal
>> with different paths on different systems.
>>
>> On x86:
>>   /usr/lib/gromacs-2/bin/wheel
>>
>> On x86_64:
>>   /usr/lib64/gromacs-2/bin/wheel
>>
>> There's two possible ways to work around this:
>> %{_libexecdir}
>>   /usr/libexec/gromacs-2/bin/wheel
>>
>> /usr/lib (*not* %{_libdir}):
>>   /usr/lib/gromacs-2/bin/wheel

Thought of a big reason not to use /usr/lib -- the binaries placed
within there would be architecture dependent.  So we'd have x86_64
binaries living in /usr/lib.

> 
> Or just fixup the path in env-module config file. That's about the only
> technical argument in favour of libexec. Using libexec doesn't require
> hacking the config files.
>
 [snip]

>>  So I don't know
>> whether that's the best place for an environment-modules directory to
>> live.  Ed, do you have a comment on whether this is a good or bad idea
>> for use of environment-modules?
> 
> I don't think it is. That's certainly a way of thinking about env-modules
> I haven't considered, but I think treating GROMACS binaries as "private"
> of environment modules makes no sense. They have nothing to do with
> env-modules and they are not private. Rather, env-modules is a convenient
> way of allowing both gromacs3 and gromacs to be installed concurrently
> and avoiding polluting %{_bindir}.

Sure, that's the way I had been thinking about them until I started
comparing it to what alternatives does.

Here's another thought:

/usr/libexec is not in the FHS, so we're using the GNU definition in
specifying that it should be used for programs that are called by other
programs.  However, the reason we include /usr/libexec in Fedora even
though it's not in the FHS is that we need someplace to put executables
that aren't in users' paths but need to match up with the host's
architecture.  This matches the description of the directory we need in
this case.

And as you say, doing path fixups in the env-module file is an alternate
way to fix things.  I just don't like having the complexity in user
scripts when this seems more straightforward.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20081008/7132f5be/attachment.sig>