#16263 closed update (invalid)
hdf5 update 1.6.7 -> 1.8.1
Reported by: | mamoll (Mark Moll) | Owned by: | jochen@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.6.0 |
Keywords: | Cc: | mamoll (Mark Moll) | |
Port: |
Description
Patched Portfile for hdf5 update
Attachments (2)
Change History (9)
Changed 16 years ago by mamoll (Mark Moll)
Attachment: | patch-Portfile.diff added |
---|
comment:1 Changed 16 years ago by jmroot (Joshua Root)
Owner: | changed from jochen to jochen@… |
---|
comment:2 Changed 16 years ago by jochen@…
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:3 Changed 16 years ago by mamoll (Mark Moll)
I understand you don't want to break existing code, but hdf5 1.8 is the official release. A 'devel' port does not seem appropriate. A better approach might be to rename the current hdf5 port to hdf5-1.6 and change dependencies of other ports (if necessary) from hdf5 to hdf5-1.6.
comment:4 Changed 16 years ago by jochen@…
There are no dependents on hdf5 directly in MacPorts, but if they were, they would break by the change you suggested -- the API is incompatible.
I foresee the same problem with the next major hdf5 release, therefore it would be best to move to a scheme of hdf-16 and hdf-18 ports for now, similar to what we have for gcc, for example. We also really don't need a "hdf5" port, it is obvious which one is newer to everybody and then they can decide what they want...
If you want to implement that (hdf5-18 + hdf5-16), please go ahead.
comment:5 Changed 16 years ago by dweber@…
I would like a copy of the updated hdf5 (ie, hdf5-18) Portfile so that I can get a working copy of the recent upgrade for netcdf, which depends on this port upgrade for hdf5.
Is there an easy way to 'undiff' the patch that was submitted for this hdf5 upgrade?
Changed 16 years ago by mamoll (Mark Moll)
Current version of my Portfile
comment:6 Changed 16 years ago by jmroot (Joshua Root)
Type: | enhancement → update |
---|
I would prefer to not update hdf5 from 1.6 to 1.8 at this point, since there are to many API incompatibilities. Instead, I would suggest to prepare a hdf5-1.8 package and use that instead. Maybe the current hdf5 port should also be renamed hdf5-1.6 and the two should be declared to conflict with each other, but in the long run that is the better path.
Alternatively, you could provide a hdf5-devel port as suggested in the Portfile, but then we still need to switch from 1.6 to 1.8 in the standard port at some point.