mpich3 -> mpich rename opinions?

[Eric A. Borisch]

Again for anyone joining in, these gyrations are due to upstream naming
changes and trying to minimize user confusion. There was once MPICH, and
then there was MPICH2, and now there is once again MPICH (v3.0).

For clarity below:
 * Upstream package names in CAPS
 * Port names in lowercase

My current plan (after more discussions with MPICH developers) is to soon:

0) Make sure gnudatalanguage and any others I missed compile fine with
mpich2 (MPICH2 v1.5) (It sounds like Sean has already confirmed this for
gnudatalanguage.)
1) Move mpich to be the same codebase as mpich2 (MPICH2 v1.5)
2) Create mpich-devel as mpich (MPICH v3.0rc1)

And once MPICH v3.0 is released:

0) Move mpich to be MPICH v3.0 (mpich-devel will match / track HEAD)
1) Set mpich3 to be 'replaced_by' mpich
2) Test other dependencies as time / motivation permits and migrate to
mpich (now at MPICH v3.0)
3) Set mpich2 to be 'replaced_by' mpich once there are no dependencies left.

 -- Eric


On Fri, Nov 16, 2012 at 5:20 PM, Sean Farley
<sean.michael.farley at gmail.com>wrote:

> On Fri, Nov 16, 2012 at 4:56 PM, Ryan Schmidt <ryandesign at macports.org>
> wrote:
> >
> > On Nov 16, 2012, at 14:58, Eric A. Borisch wrote:
> >
> >> I'm considering updating the 'mpich' portfile to version 3.0rc1; this
> is currently available as 'mpich3.'
> >>
> >> Background: The upstream project has changed naming conventions; they
> previously had mpich (now at 1.2.7p1) and mpich2 (at 1.5). With the
> implementation of the MPI-3 standard (mpich2 was MPI-2, etc.) they've gone
> back to the mpich name, and they've requested that our (my) mpich3 port
> replace the (nomaintainer) mpich port for consistency.
> >>
> >> There are no ports that currently depend on 'mpich' .. any other
> concerns with making this change (and setting a replaced_by in mpich3 for
> the next year before pruning it?)
> >
> > There is one port that depends on mpich: gnudatalanguage
>
> I once maintained a version of gnudatalanguage that used mpich2:
>
>
> https://bitbucket.org/seanfarley/scienceports/src/32b478a0654b/math/gnudatalanguage/Portfile?at=default
>
> It is a trivial change.
>
> > But your plan sounds good to me.
> >
> > Will the mpich2 port survive or will it also be replaced by the mpich
> port? There are many ports depending on mpich2.
>
> It is planned to replace mpich2 by mpich 3.0. As someone that works in
> the same department as the mpich group and, more importantly, someone
> that actually uses mpi, I have the following suggestions:
>
> * remove lammpi; it has long since been abandoned for openmpi
> * have openmpi{,-devel} conflict with mpich{,2,-devel} and drop the
> openmpicc business (so that all dependent ports can check for
> path:bin/mpicc)
> * replace mpich by mpich 3.0
> * leave mpich2 for now
>
> I have implemented these changes in my scienceports repo (with the
> added compiler variants via my custom portgroup [1]), so feel free to
> pick and chose which parts you want to copy:
>
>
> https://bitbucket.org/seanfarley/scienceports/src/b4bac6a7317a8f94c29ce39e81ae693d5a3503f0/science/openmpi/Portfile?at=default
>
> https://bitbucket.org/seanfarley/scienceports/src/b4bac6a7317a8f94c29ce39e81ae693d5a3503f0/science/mpich/Portfile?at=default
>
> Hmmm, be careful if you copy the version as 3.0rc1. I was being lazy
> about that but I'd prefer not to force an epoch increase, if possible.
>
> [1]: https://trac.macports.org/ticket/35360
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20121116/71115519/attachment.html>