packaging mpich2 -- conflicts with lam and file layoutb

[Jeff Spaleta]

On 11/8/05, Ed Hill <ed at eh3.com> wrote:
> So, reading the man pages, alternatives boils down to a bunch of
> symbolic links.  Well, that stinks (tm).  I want multiple MPI
> implementations installed side-by-side and I want to select, for
> instance, which "mpirun" is called on a *** per-session basis *** by
> either specifying its full path or by using some semi-automated ${PATH}
> manipulation magic such as:
>
>   http://modules.sourceforge.net/
>
> as discussed at:
>
>   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171993
>
> So, my question for the packaging-gurus becomes:  Is there some way that
> we can accomplish that using something like (that is, similar but
> perhaps not exactly the same as):

You run the risk of breaking the fhs by placing binaries in their own
dedicated path structures.
The use of /usr/local to make versioned paths is pretty much
unacceptable for Fedora Extras.

The binaries must live in an fhs compatible location for binaries, and
the approach that alternatives uses..to give binaries unique names in
the same path is pretty much the only way you are going to accomplish
this.

If you want to layer on per-user evironment "module" support over
that..fine. But you can not do it in a way that puts the actual
binaries in versioned directories. It would however be pefectly
appropriate to provide "module" support via symlinks back to the real
binaries
and use a path like /usr/share/mpich2/version/env-modules/  in your
per-user path manipulation. The environment modules idea does not
require the actual binaries to live in versioned directories, a
directory with symlinks to the actual binaries will suffice.  This way
the actual binaries are still available in the default path, with a
system default defined via alternatives...with per user module
manipulation riding over top to make per-module path manipulations to
override the system defaults.

-jef