packaging mpich2 -- conflicts with lam and file layoutb

[Tom 'spot' Callaway]

On Tue, 2005-11-08 at 11:42 -0500, Deji Akingunola wrote:
> Hi Tom,
> 
> > I'd rather do this:
> >
> > %{_libdir}/${MPI_IMPL_NAME}/
> > %{_includedir}/${MPI_IMPL_NAME}/
> >
> > And use something like alternatives to manage the binaries, without
> > putting them in a "magic" dir that violates the FHS.
> >
> If I understand you very well, you mean doing it the jpackage/java way
> - putting the _bindir, _libdir, and _includedir in 
> %{_libdir}/${MPI_IMPL_NAME}/ - is discouraged and should not be used ?

Yes. This violates the FHS. Thou shalt not put binaries in /usr/lib, nor
in /usr/include.

> The problem using the style you proposed above, is that these
> different mpi implementations provides the same standard mpi binaries
> {mpicc,mpicxx,mpif90,mpif77,mpirun}, and man pages too. How can those
> be taken care of.

Binaries need to live in %{_bindir}. By using alternatives, you can
choose the implementation which provides "mpicc". The catch is that each
package which provides "mpicc" needs to rename that to
"mpicc.${MPI_IMPL_NAME}". I'm willing to work with the lam maintainer to
make sure that we do this for FC5.

Look at sendmail and postfix for an example of how this should work.

~spot
-- 
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!