Request for help with port organisation: how to install several versions of data files

Ryan Schmidt ryandesign at macports.org
Mon Jul 1 15:13:02 PDT 2013


On Jul 1, 2013, at 07:48, Mojca Miklavec wrote:

> I'm looking for ideas about how to best organise the port(s) for
> Geant4 data files (see also https://trac.macports.org/ticket/32716).
> 
> Geant4 needs approximately 8 data files which currently looks like this:

> I would like to provide multiple versions of Geant4 simultaneously
> (for example two or three versions) and as part of the process, Frank
> Schima suggested separating the data files from the source code into
> (a) different port(s).

I agree separating data files from code can be useful, but I would try to put all the data files relating to a specific version of geant4 into a single port (or subport), and not do one port (or subport) per file and version.

The reason is that if today you make the user install geant-something-1.1 and tomorrow you update geant to depend on geant-something-1.2 then the upgrading user will still be left with geant-something-1.1 installed for no reason: old versions of these dependencies will just accumulate with no easy way for the user to see that they're no longer needed, since they'll still be listed as active. Even upgrading geant with "sudo port -u upgrade" wouldn't remove these old versions.

If it is possible that, say, geant4.9.5 and geant4.9.6 would use the same version of some dependency, then you'd have to make a separate data directory for each geant4 version, for example /opt/local/share/Geant4.9.5/Data, and put all the data files for that version in there.


> Each <name>-<version> would then fetch a single tar.gz file from the
> server, check the md5 checksum (or some other sum - md5 is simply the
> one provided upstream), and extract it to a place like this:
> 
>     /opt/local/share/Geant/Data/G4EMLOW6.31/
>     /opt/local/share/Geant/Data/G4EMLOW6.32/
>     /opt/local/share/Geant/Data/G4EMLOW6.33/
>     /opt/local/share/Geant/Data/RealSurface1.0/
>
md5 is an insecure algorithm and should no longer be used on its own as a means of verifying anything. If that's all upstream publishes, then you can use it in a portfile, in addition to a secure algorithm like rmd160 or sha256, but please ask upstream to switch to a secure checksum method for their published values.



More information about the macports-dev mailing list