The role of %{_libexecdir} for using environment-modules
On Wednesday, 08 October 2008 at 22:52, Toshio Kuratomi wrote:
> 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.
Here's an old discussion that seems to have good arguments to support
your view:
http://www.redhat.com/archives/rhl-devel-list/2005-May/msg00240.html
So, I have no further objections against using /usr/libexec.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
|
