Hi,


I'm working on a couple of packages (gromacs and gromacs3) that are
going to use environment-modules since they have a lot of binaries that
otherwise would go to /usr/bin and some of them have very generic names
(e.g. wheel, luck and highway). This way a user can have both the new
release series and the old stable series installed and decide which
version to use.

What is the correct place to put these (architecture dependent)
binaries? Is it OK to use %{_libexecdir}/%{name} (or
%{name}-%{version}) ?
--
------------------------------------------------------
Jussi Lehtola, FM, Tohtorikoulutettava
Fysiikan laitos, Helsingin Yliopisto
jussi.lehtola@helsinki.fi, p. 191 50623
------------------------------------------------------
Mr. Jussi Lehtola, M. Sc., Doctoral Student
Department of Physics, University of Helsinki, Finland
jussi.lehtola@helsinki.fi
------------------------------------------------------

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Moderator note:
I let this one through the moderation queue, please be sure to CC Jussi
on all replies.

~spot

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Hi Jussi

> I'm working on a couple of packages (gromacs and gromacs3) that are
> going to use environment-modules since they have a lot of binaries
> that
> otherwise would go to /usr/bin and some of them have very generic
> names
> (e.g. wheel, luck and highway). This way a user can have both the new
> release series and the old stable series installed and decide which
> version to use.

It would be better to use alternatives for this.

Look at MTA packages or other packages that do this kind of thing already.

I am not familiar with gromacs: is it really necessary to include both in Fedora?: normally we just tend to ship the latest major release.

Jens

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Tue, 7 Oct 2008 20:07:39 -0400 (EDT) Jens Petersen wrote:
>
> > I'm working on a couple of packages (gromacs and gromacs3) that are
> > going to use environment-modules since they have a lot of binaries
> > that
> > otherwise would go to /usr/bin and some of them have very generic
> > names
> > (e.g. wheel, luck and highway). This way a user can have both the
> > new release series and the old stable series installed and decide
> > which version to use.
>
> It would be better to use alternatives for this.
>
> Look at MTA packages or other packages that do this kind of thing
> already.
>
> I am not familiar with gromacs: is it really necessary to include
> both in Fedora?: normally we just tend to ship the latest major
> release. Jens


Hi folks,

*Please* stop suggesting alternatives.

Alternatives is a total failure for user-space applications that are
not *completely* generic and 100% interchangeable. Lets illustrate
this point with three use cases:

Use case 1 : Two users (Alice and Bob) are using the same system
(machine) at the same time. Alice must use MPI implementation
"A" since it is the only one that works properly with her
application. And Bob wants to use the "B" implementation since
it is the one that works best for his application. Since
alternatives is a *system-wide* setting, it can only satisfy one
user a time -- never both. Thus, it is a total failure for this
use case.

Use case 2 : A single user (Carl), wants to run two programs
(Foo and Bar) simultaneously. The Foo program feeds its results
to the Bar program. And the Foo program requires the "A" MPI
implementation while Bar requires the "B" implementation. Since
alternatives is a system-wide configuration setting, Carl cannot
run the two programs at the same time. Again, alternatives is
not up to the task.

Use case 3 : Dan and Evan both want to use the Baz program but Dan
requires certain features only available with Baz v1.0 while
Evan must have features only present in Baz v2.0. As in use case
#1, both Dan abd Evan are trying to use the same machine.


Please notice that modules (aka "environment modules") is a perfectly
workable solution for all the above scenarios and it does not require
any help from an admin (or root/sudo perms).

Ed

--
Edward H. Hill III, PhD | ed@eh3.com | http://eh3.com/
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Hi Ed,

> *Please* stop suggesting alternatives.

Ok, I hear what you're saying and think you have a point.

On the other hand using alternatives would mean having to install the programs in separate "namespaces" in the filesystem anyway and then the alternatives would just determine which of the two are default: it only has to worry about conflicting files. But I take you point that using wrappers and environment variables say might provide a cleaner more generic solution. I don't know of any packages that use that off hand in fedora but as I said we tend not to ship multiple major versions of projects afap: so first of all it would be good to understand why both are needed, but that is getting a bit off topic so that conversation probably would be better done in fedora-devel-list.

Jens

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Tue, 2008-10-07 at 21:15 -0400, Ed Hill wrote:
> Hi folks,
>
> *Please* stop suggesting alternatives.
>
> Alternatives is a total failure for user-space applications that are
> not *completely* generic and 100% interchangeable. Lets illustrate
> this point with three use cases:
>
> Please notice that modules (aka "environment modules") is a perfectly
> workable solution for all the above scenarios and it does not require
> any help from an admin (or root/sudo perms).


Exactly. Now the question still remains where to hide these. OpenMPI
puts its wrappers in /usr/share/openmpi, but /usr/share is for
architecture independent data.

Since /usr/bin doesn't have any subdirectories to me it seems quite
straightforward to use /usr/libexec/%{name} to "hide" the binaries. They
are then automatically added to the path upon loading the module.

My interpretation is that this is OK according to the Packaging
guidelines: "Libexecdir (aka, /usr/libexec on Fedora systems) should be
used as the directory for executable programs that are designed
primarily to be run by other programs rather than by users."

Alternatives are out of the question: at the moment, there are 184
belonging to the package. Also the users of the software are quite
probably used to environment-modules, since they've been standard
equipment on supercomputers for a long time.
--
------------------------------------------------------
Jussi Lehtola, FM, Tohtorikoulutettava
Fysiikan laitos, Helsingin Yliopisto
jussi.lehtola@helsinki.fi, p. 191 50623
------------------------------------------------------
Mr. Jussi Lehtola, M. Sc., Doctoral Student
Department of Physics, University of Helsinki, Finland
jussi.lehtola@helsinki.fi
------------------------------------------------------

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Wed, Oct 08, 2008 at 10:28:35AM +0200, Denis Leroy wrote:
>
> As for finding the binaries, I would personally prefer to patch the code
> to look for the binaries in the packaged directory rather than use
> profile.d.

Agreed, with the addition than the env variables should still be taken
into account, but in case they are not defined, the default paths should
be the right ones.

--
Pat

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Wed, 08 Oct 2008 09:57:46 +0300 Jussi Lehtola wrote:
> On Tue, 2008-10-07 at 21:15 -0400, Ed Hill wrote:
> >
> > *Please* stop suggesting alternatives.
> >
> > Alternatives is a total failure for user-space applications that are
> > not *completely* generic and 100% interchangeable. Lets illustrate
> > this point with three use cases:
> >
> > Please notice that modules (aka "environment modules") is a
> > perfectly workable solution for all the above scenarios and it does
> > not require any help from an admin (or root/sudo perms).
>
>
> Exactly. Now the question still remains where to hide these. OpenMPI
> puts its wrappers in /usr/share/openmpi, but /usr/share is for
> architecture independent data.
>
> Since /usr/bin doesn't have any subdirectories to me it seems quite
> straightforward to use /usr/libexec/%{name} to "hide" the binaries.
> They are then automatically added to the path upon loading the module.
>
> My interpretation is that this is OK according to the Packaging
> guidelines: "Libexecdir (aka, /usr/libexec on Fedora systems) should
> be used as the directory for executable programs that are designed
> primarily to be run by other programs rather than by users."


Yes!!!

And +1 for a convention such as

/usr/libexec/%{name}
/usr/libexec/%{name}-%{version}

that allows both names and, if desired, versions.

Ed

--
Edward H. Hill III, PhD | ed@eh3.com | http://eh3.com/
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Wednesday, 08 October 2008 at 15:28, Ed Hill wrote:
> On Wed, 08 Oct 2008 09:57:46 +0300 Jussi Lehtola wrote:
> > On Tue, 2008-10-07 at 21:15 -0400, Ed Hill wrote:
> > >
> > > *Please* stop suggesting alternatives.
> > >
> > > Alternatives is a total failure for user-space applications that are
> > > not *completely* generic and 100% interchangeable. Lets illustrate
> > > this point with three use cases:
> > >
> > > Please notice that modules (aka "environment modules") is a
> > > perfectly workable solution for all the above scenarios and it does
> > > not require any help from an admin (or root/sudo perms).
> >
> >
> > Exactly. Now the question still remains where to hide these. OpenMPI
> > puts its wrappers in /usr/share/openmpi, but /usr/share is for
> > architecture independent data.
> >
> > Since /usr/bin doesn't have any subdirectories to me it seems quite
> > straightforward to use /usr/libexec/%{name} to "hide" the binaries.
> > They are then automatically added to the path upon loading the module.
> >
> > My interpretation is that this is OK according to the Packaging
> > guidelines: "Libexecdir (aka, /usr/libexec on Fedora systems) should
> > be used as the directory for executable programs that are designed
> > primarily to be run by other programs rather than by users."
>
>
> Yes!!!
>
> And +1 for a convention such as
>
> /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.
Some packages do that (that is, keep their binaries there).

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

On Wed, 8 Oct 2008 15:38:15 +0200 "Dominik 'Rathann' Mierzejewski"
wrote:
> On Wednesday, 08 October 2008 at 15:28, Ed Hill wrote:
> >
> > And +1 for a convention such as
> >
> > /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.
> Some packages do that (that is, keep their binaries there).


What reason(s) do you have for the preference ?

If you use %{_libdir} then you will have to deal with multi-lib which,
in my opinion, needlessly complicates paths in the environment-modules
files.

If you use %{_libexecdir} then you do *not* have to worry about any
multilib issues -- they are automatically sorted out for you.

Ed

--
Edward H. Hill III, PhD | ed@eh3.com | http://eh3.com/
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging