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

[Mojca Miklavec]

On Tue, Jul 2, 2013 at 11:45 AM, Ryan Schmidt wrote:
> 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.

So what is the difference between the two scenarios then? (Your
suggestion was to do (b).)
a) geant4.9.5 depends on geant-something-1.1 and
geant-somethingelse-3.0; geant4.9.6 depends on geant-something-1.2 and
geant-somethingelse-3.0
b) geant4.9.5 depends on geant4.9.5-data and geant4.9.6 depends on
geant4.9.6-data

When the user will switch from 4.9.5 to 4.9.6, the "something-1.1"
will be left in either case. Except that in (b) also another copy of
"somethingelse-3.0" will stay on the hard drive, so one will get a
leftover of 600 MB instead of a leftover of 100 MB.

The approach (b) would only work (= clean old files) if geant4 would
depend on geant4-data and there would be no option to install two
versions of geant4 or two versions of geant4-data.

>> 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.

Do you want to say that changing
    name                geant4-data
    version             1.0
to
    name                geant4-data
    version             1.1
or "revision 1/2/3/..."

will update all files? Or that even adding a new subport will
reinstall all installed subports?

The idea is that once "geant-data-something-3.1" is installed, that
particular subport never changes again. At least that's the theory.
(In particular these ports won't have to be updated because "libpng
got updated and we need to rebuild them".)


> 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 just want to clarify a bit: My idea was to provide, say, geant4.9.5
and geant4.9.6. The versions of data files change when going from
beta1 -> beta2 -> beta3 -> ... -> first release -> patch 1 -> patch 2
-> ..., but the versioned data files never change themselves. So
unless adding a new subport really reinstalls all subports, I still
believe that having ports geant-something-1.1 would be better than
having geant4.9.5-data.

>> 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.

OK.

>> 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.

Sure. But where should I get the checksums from? If the files are
already compromised when the maintainer downloads them, so can be the
published checksums. What then? (Or, one of the Geant4 developers can
just as well put some evil or at least vulnerable code into the
official distribution. Who is going to notice?)

I'm not saying that there is no security risk, but if it gets
compromised to that level, there's not much one can do.

Mojca