On Oct 4, 2012, at 17:27, Jeremy Lavergne <jer...@lavergne.gotdns.org> wrote:
>> I've agreed before that we should do this split, in favor of having >> variants. I agree it'll be a major pain to do. >> >> The goal would be to have the quartz and x11 subports simultaneously >> installable. >> >> But at that point, does anything speak against just making pango/cairo/gtk2 >> always install both quartz and x11 parts and just get rid of the variants? >> Is that even possible? > > Other than avoiding the x11 dependency tree... Ah. Right. The desire not to have to install x11 bits. I suppose that's a valid request. > I'm not sure if a package somewhere requires -quartz or -x11. Right, I was wondering about that. But I'm hoping there isn't. > Some ports catch my eye (their patchfile names): > * py-enable: no-64-bit-quartz.diff > * qjackctl: patch-configure-no-x11.diff > * gecko-sharp2 > * aalib I haven't looked at these. > It might also defeat the purpose of some x11 subports: > * freeciv/freeciv-x11 No, here this gives the user the choice of whether they want to run freeciv in x11 mode or not. That's still a valid choice, and one that has to be made at compile time for this port (and I suspect other ports). > Also several ports have a default_variants for -x11: > * giflib > * openvrml No, this is only part of the compatibility code assisting users in upgrading from the no_x11 variant. Users not specifying a variant will still get x11 by default, as we've so far standardized on with other ports. > * pspp-devel This port doesn't mention -x11. > And of course, all the packages with their own x11 variants to help guide the > dependency tree to use x11. Yes. It had thus far been an unwritten (?) rule that if a port can include x11 support, then it should be on by default. This rule probably originated at a time when x11 was an on/off switch (and thus in line with our desire to turn as many useful features on as possible by default), rather than an either/or choice with quartz. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
