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

David Strubbe dstrubbe at macports.org
Thu Jan 14 07:50:28 PST 2016


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 <ryandesign at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160114/b16db34a/attachment-0001.html>


More information about the macports-dev mailing list