Changing port group default options

[Mojca Miklavec]

On Tue, Mar 31, 2015 at 5:12 PM, Rainer Müller wrote:
>
> Futhermore, while we can fix all the Portfiles in the official tree by
> search and replace, we do not know whether others keep private port
> trees affected by such changes.

Keep in mind that private ports that aren't occasionally kept up to
date are sooner or later bound to cause problems in one way or
another.

Assume that port A depends on B. User creates a private copy of B and
keeps it outdated. After a while port A could require the latest
version of B and the users' installation will break both because port
B will stay at an incompatible version and also because fetching a
binary archive of A will link against libBsomething.3.dylib, while B
would provide libBsomething.2.dylib.

Or, assume a user keeping p5-foo in a local tree with "perl.versions
5.8 5.10 5.12 5.14 5.16". Then we decide to drop support for 5.16
altogether and keep just 5.22. If the user tries to install p5.22-bar
that depends on p5.22-foo, it will fail on that user's machine.

(It's not purely theoretically. I'm bitten by such problems every now
and then, but "luckily" it's "difficult enough" to set up a local
repository, so that users who manage to set that should also be able
to fix the problem by updating/removing the problematic & outdated
ports.)


In my opinion increasing the version of the portgroup should be
reserved for (fundamentally) incompatible changes or when the syntax
changes. (For example when switching from qt4 to qt5 if the portgroup
would initially be just "qt". Or if the python PortGroup would start
working for software written in C++ with Python bindings.) I agree
that this kind of change in the cmake PortGroup is almost the
bordercase, but I feel that starting a new revision would introduce
way more work than benefits.

Mojca