KMyMoney4 +no_gtk +no_x11 fails because gtk is installed anyway and more...

Ryan Schmidt ryandesign at macports.org
Thu Oct 4 15:58:37 PDT 2012


On Oct 4, 2012, at 17:27, Jeremy Lavergne <jeremy at 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.




More information about the macports-dev mailing list