On 04.03.2015 03:26 PM, Brandon Allbery wrote: > On Wed, Mar 4, 2015 at 6:29 AM, René J.V. <[email protected] > <mailto:[email protected]>> wrote: > > 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? > > > Port bugs are never OK. A diagnostic/debugging mode that is forced on > in some port as a hackaround for port bugs instead of fixing the port > is *also* never OK.
That's generally true. I do however think that port maintainers can not be asked to willy-nilly fix *complex* broken build systems. Our current workaround for this is the conflicts_build PortGroup, which bails out and asks the user to deactivate the port in question. This is ugly for several reasons: - it requires interactivity - a deactivated port is not listed in ``port outdated'' and can NOT be used with ``port upgrade'', but must be re-installed with ``port installed''. This is totally counter-intuitive. (And yes, I know, not mentioned anywhere...) Forcing trace mode for those specific ports would at least, though not fixing the underline cause, fix the problems listed above. Maybe I'm biased, because I'm directly affected by this. I've had users complain explicitly about this, though. Mihai
signature.asc
Description: OpenPGP digital signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
