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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev