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

[Ryan Schmidt]

On Jul 2, 2013, at 03:44, Mojca Miklavec wrote:

> Let's say that I indeed create, say, geant4.9.5-data and
> geant4.9.6-data (let's say that these are two subports which install
> all the data files into version-specific directory). User who decides
> to install geant4.9.5 would get at least the following dependencies
> automatically:
> - expat
> - clhep
> - root
> - geant4.9.5-data
> 
> What happens when user:
> a) decides to uninstall geant4.9.5

geant4.9.5 is uninstalled.


> b) decides to install geant4.9.6 and to uninstall geant4.9.5

geant4.9.6 and any required dependencies are installed and geant4.9.5 is uninstalled.


> Would geant4.9.5-data be removed then?

Not unless the user asks for that to happen.


> What about root, clhep, expat
> which would also be no longer needed after removing geant4?

They remain, unless the user asks to uninstall them.


> How can
> user get rid of packages in that case?

The user could "sudo port uninstall leaves". "leaves" are ports that no other installed ports depend on, and that the user did not explicitly request (i.e. that were installed as a dependency of something else).

So that is a solution. The point is that the strategy of creating a (sub)port per data file per data file version will result in the creation of a leaf every time you update any of those data files' versions. Whereas my proposal of bundling all data files into a single data files port per geant version will only create a single leaf and only if the user decides to switch to a different geant version and uninstall the old geant version. However, my proposal has the downside that all data files have to be reinstalled anytime any of them changes, which means longer install times and larger prebuilt packages. But that's already what's happening in the geant4 port now.


> I'm asking because I often have similar "problems". As soon as I
> install wine[-devel] it becomes a problem to get rid of all the
> universal packages that need to be upgraded and compiled from source
> over and over again.

That's a different issue, that I think we (or at least I) have talked about before, and I'm not aware of a straightforward solution for de-universalizing one's MacPorts installation.


> I remember I saw a command listing all ports that were "not requested"
> and did not have any dependents. That one could be used to uninstall
> such packages.

That's "leaves".


> It would also be an option to try to
> deactivate/uninstall data packages when deactivating/uninstalling
> geant4 provided that they wouldn't be used by any other port. (I'm not
> necessarily saying that this is a good idea because I'm definitely not
> aware of all the implications of such approach.)

Some ports need to deactivate other ports at activation time to ensure a smooth experience, so we have the "deactivate hack" in the PortfileRecipes for that. But I don't think we have any ports that uninstall other ports, so I don't think users would expect for that to happen, so I would not encourage pursuing that idea.


>> If it is possible that, say, geant4.9.5 and geant4.9.6 would use the same version of some dependency,
> 
> It is.
> 
>>> 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,
> 
> It is. But I can generate other checksums manually (with help of "port
> -v extract") of course.

But be clear that the file you download from upstream could already be compromised, if it's only being verified by an md5 checksum. Thus, you could be generating new "secure" checksums of an already compromised file.


>> but please ask upstream to switch to a secure checksum method for their published values.
> 
> OK, I'll ask them.