Opened 12 years ago

Closed 12 years ago

#37785 closed defect (fixed)

Ports depending on mpich2: move to mpich

Reported by: eborisch (Eric A. Borisch) Owned by: eborisch (Eric A. Borisch)
Priority: Normal Milestone:
Component: ports Version: 2.1.2
Keywords: haspatch Cc: adfernandes (Andrew Fernandes), dweber@…, humem (humem), mamoll (Mark Moll), mww@…, raimue (Rainer Müller), skymoo (Adam Mercer), tenomoto (Takeshi Enomoto)
Port: mpich2

Description

The MPICH project has named version 3 of the software as MPICH v3.0 (rather than continuing on MPICH2 to become MPICH3.) The mpich[-devel] port has been moved (r100087) to this up-to-date version.

At this time, I'm ready to move all ports that depend on MPICH2 to MPICH (v3), as well as to mark MPICH2 as replaced_by MPICH. (These two steps could be done separately -- suggestions on if this should be an atomic change, or two changes -- and in which order?)

I have attached a patch that does just that. I have copied all portfile owners associated, and I will post on the -dev list (linking to this ticket) about this change.

I plan to apply the patch next week unless there are concerns raised.

Attachments (2)

mpich2_to_mpich.diff (18.3 KB) - added by eborisch (Eric A. Borisch) 12 years ago.
mpich2_to_mpich-with-extra-variant.diff (31.9 KB) - added by eborisch (Eric A. Borisch) 12 years ago.

Download all attachments as: .zip

Change History (12)

Changed 12 years ago by eborisch (Eric A. Borisch)

Attachment: mpich2_to_mpich.diff added

comment:1 Changed 12 years ago by skymoo (Adam Mercer)

In fftw3 the relevant variant is named mpich2, would it make sense to rename this variant?

comment:2 Changed 12 years ago by eborisch (Eric A. Borisch)

I debated that myself and figured I'd leave it to each maintainer to decide...

I think it would make sense to change it, perhaps leaving the +mpich2 variant but have it raise a ui_error that the variant has been renamed (so those that had fftw3 +mpich2 installed don't end up with fftw3 (no variants) after upgrade.)

Or is there a replaced_by equivalent for variants?

comment:3 Changed 12 years ago by mf2k (Frank Schima)

Owner: changed from eborisch to eborisch@…

There is no replaced_by for variants. I would just rename them.

comment:4 Changed 12 years ago by jmroot (Joshua Root)

You can make a variant require another variant, so you can change the old variant to do nothing but require the new one.

comment:5 Changed 12 years ago by eborisch (Eric A. Borisch)

Here's a link to the mailing list discussion for the record: https://lists.macosforge.org/pipermail/macports-dev/2013-January/021796.html

Changed 12 years ago by eborisch (Eric A. Borisch)

comment:6 Changed 12 years ago by eborisch (Eric A. Borisch)

I've added a new .diff file that includes renaming +mpich2 variants to +mpich and adding a new (empty) +mpich2 variant that requires +mpich. If there are no new concerns raised, I'll be committing it next week. The +mpich2 variants could be removed eventually as they exist solely to ease upgrades.

comment:7 Changed 12 years ago by eborisch (Eric A. Borisch)

Cc: mww@… raimue@… added

Adding some maintainers I missed on copy. I'll wait for them to have a chance to look it over, too.

comment:8 Changed 12 years ago by raimue (Rainer Müller)

I went ahead and committed the changes to valgrind and valgrind-devel in r102485.

comment:9 Changed 12 years ago by eborisch (Eric A. Borisch)

Changes committed in r103204.

comment:10 Changed 12 years ago by larryv (Lawrence Velázquez)

Resolution: fixed
Status: newclosed

I’m assuming this is okay to close.

Note: See TracTickets for help on using tickets.