On Wednesday March 04 2015 10:51:06 Chris Jones wrote: > Personally, I think what it does is *always* correct.
Aren't you relying on the assumption that all ports register all the files they install? What happens to files installed because of some port C that are used by port A while it builds, how are you going to block them if port C is not on the dependency list? There were discussions not that long ago that showed that there are classes of files that get installed by ports but not registered for a reason. >So no, I don't personally think there should be a way for ports to opt >in or out. So to you it's OK if a port fails to build because it pulls in things from an earlier, installed version of itself that were not blocked because the feature was not enabled, and do so without as much as an explanation? I'd be in favour of a more pragmatic approach, and allow opt-in (require it) when the feature is disabled globally (in macports.conf, possibly with a warning), which turns to an error when the feature was disabled on the commandline. That's not unlike how dependencies are handled: nothing is done when they're already installed, they're installed when needed unless the user takes action to prevent that - in which case an error is raised at some point. R. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
