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

[David Strubbe]

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

Re: [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.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ryan Schmidt]

> On Jan 13, 2016, at 11:29 AM, dstru...@macports.org wrote:
> 
> Revision
> 144607
> Author
> dstru...@macports.org
> Date
> 2016-01-13 09:29:21 -0800 (Wed, 13 Jan 2016)
> Log Message
> 
> octopus: Make +accelerate the default, to save a lot of time in building 
> atlas.
> Modified Paths
> 
>   • trunk/dports/science/octopus/Portfile
> Diff
> 
> Modified: trunk/dports/science/octopus/Portfile (144606 => 144607)
> 
> --- trunk/dports/science/octopus/Portfile 2016-01-13 16:51:07 UTC (rev 
> 144606)
> +++ trunk/dports/science/octopus/Portfile 2016-01-13 17:29:21 UTC (rev 
> 144607)
> @@ -6,7 +6,7 @@
>  
>  nameoctopus
>  version 5.0.1
> -revision0
> +revision1
>  categories  science
>  platforms   darwin
>  license GPL-2+
> @@ -52,7 +52,7 @@
>  
>  default_variants +newuoa
>  if {![variant_isset accelerate] && ![variant_isset openblas]} {
> -default_variants-append +atlas
> +default_variants-append +accelerate
>  }


But there was no reason to increase the port's revision, since the user's 
existing variants will be preserved in the upgrade. Regardless whether the user 
had the atlas or accelerate or openblas variant of octupus 5.0.1_0 installed, 
they will have exactly the same variant of octopus 5.0.1_1 installed after the 
upgrade. Increasing the revision only causes lots of unnecessary rebuilding, 
for the buildbots and for users.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ryan Schmidt]

On Jan 13, 2016, at 11:45 AM, Ryan Schmidt wrote:

> But there was no reason to increase the port's revision, since the user's 
> existing variants will be preserved in the upgrade. Regardless whether the 
> user had the atlas or accelerate or openblas variant of octupus 5.0.1_0 
> installed, they will have exactly the same variant of octopus 5.0.1_1 
> installed after the upgrade. Increasing the revision only causes lots of 
> unnecessary rebuilding, for the buildbots and for users.

I should correct myself, and say it causes unnecessary rebuilding or 
downloading and reinstalling for users. The buildbots will have to rebuild 
regardless whether the revision is changed, because the variants are changed, 
but that's fine.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[David Strubbe]

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.

David

On Wed, Jan 13, 2016 at 12:47 PM, Ryan Schmidt 
wrote:

>
> On Jan 13, 2016, at 11:45 AM, Ryan Schmidt wrote:
>
> > But there was no reason to increase the port's revision, since the
> user's existing variants will be preserved in the upgrade. Regardless
> whether the user had the atlas or accelerate or openblas variant of octupus
> 5.0.1_0 installed, they will have exactly the same variant of octopus
> 5.0.1_1 installed after the upgrade. Increasing the revision only causes
> lots of unnecessary rebuilding, for the buildbots and for users.
>
> I should correct myself, and say it causes unnecessary rebuilding or
> downloading and reinstalling for users. The buildbots will have to rebuild
> regardless whether the revision is changed, because the variants are
> changed, but that's fine.
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev