Ok, thanks for the explanation. And the fix to my logic in the Portfile. David
On Thu, Jan 14, 2016 at 8:14 AM, Ryan Schmidt <ryandes...@macports.org> wrote: > > 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. > > >
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev