Opened 11 years ago
Closed 11 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)
Change History (12)
Changed 11 years ago by eborisch (Eric A. Borisch)
| Attachment: | mpich2_to_mpich.diff added |
|---|
comment:1 Changed 11 years ago by skymoo (Adam Mercer)
comment:2 Changed 11 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 11 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 11 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 11 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 11 years ago by eborisch (Eric A. Borisch)
| Attachment: | mpich2_to_mpich-with-extra-variant.diff added |
|---|
comment:6 Changed 11 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 11 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 11 years ago by raimue (Rainer Müller)
I went ahead and committed the changes to valgrind and valgrind-devel in r102485.
comment:10 Changed 11 years ago by larryv (Lawrence Velázquez)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I’m assuming this is okay to close.
In
fftw3the relevant variant is namedmpich2, would it make sense to rename this variant?