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
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
