[prev in list] [next in list] [prev in thread] [next in thread] 

List:       macports-dev
Subject:    Re: KMyMoney4 +no_gtk +no_x11 fails because gtk is installed anyway and more...
From:       Ryan Schmidt <ryandesign () macports ! org>
Date:       2012-10-04 22:58:37
Message-ID: 5F5076F8-854B-466B-8F41-ABEFEBF8E3E0 () macports ! org
[Download RAW message or body]


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


[prev in list] [next in list] [prev in thread] [next in thread]