[144607] trunk/dports/science/octopus/Portfile

[Ryan Schmidt]

On Jan 13, 2016, at 11:53 AM, David Strubbe wrote:

> Oh ok. I have seen some ports have a revision increased recently because of a change of default variants, so I was following that, but I guess they shouldn't have been.

It varies. You just need to ask yourself: will this change result in a change* in the files installed on the system of a user who already has this port installed? If yes, increase the revision. If no, don't increase the revision.


* Perhaps I should say "significant change". Yes, any change in the Portfile results in a change in the files that would be installed on the user system, in that the Portfile itself is installed onto the user system. But I would ignore that for insignificant changes to the Portfile, such as whitespace changes or syntax changes that don't result in functional changes.


Take the example of a port that does not support X11. (It uses configure.args --without-x11.) You now want to offer X11 support in a variant and, by MacPorts convention, you want to enable it by default. You add to the port something like this:

variant x11 {
    configure.args-replace --without-x11 --with-x11
    depends_lib-appen port:xorg-libX11
}

default_variants +x11

This will result in a change in the files installed on the user system: before, they had a program that did not support X11, and after rebuilding, they will have a program that does support X11. So the revision of that port should be increased when that change is made.


That's not the situation in octopus. In octopus you have three variants which are mutually exclusive and one of them was the default. Note that the previous default was only selected if another option had not already been selected by the user. That's what the if statement (which I corrected in r144637) does. And know that variants (regardless whether the user selected them explicitly or whether they were a default variant at the time the user installed the port) are preserved on upgrades. So changing the default amongst a set of variants where it is required for the user to select one of the variants cannot result in a change to the files on the user's system, so the revision should not be increased when the default is changed.


If you notice that a port would optionally use a dependency, when you add the dependency to the port, you increase the revision, because it would result in a change of functionality for those users who did not already happen to have that dependency installed (which includes all users who received a binary from the buildbot).


If you notice a port that is missing a required dependency, the port would fail to build for users who did not happen to already have the dependency installed, which would include the buildbot. For any users who happened to already have the dependency installed, they might not know that the port has that dependency, and MacPorts would not prevent them from uninstalling the dependency, which would break the port. Therefore, when you add the dependency to the port, you still increase the revision, so that the port's dependencies are correctly recorded in the registry and MacPorts correctly prevents their uninstallation.


If a port has a custom pre-activate, post-activate, pre-deactivate or post-deactivate block, and significant changes in those blocks require a revision increase, because MacPorts runs those blocks from the copy of the Portfile that was installed on the user system, not the current version of the Portfile in the ports tree.


Just a few examples of situations to consider.