X11 in Macports

[Ryan Schmidt]

On Nov 22, 2008, at 23:00, Jeremy Huddleston wrote:

> For those of you who don't know me, I took over development of X11  
> in OSX when Ben Byer moved on to bigger and better things at the  
> beginning of 2009.

Shhhh! I thought people weren't supposed to know you have a time  
machine. :)


> I've been poke, prodded, nudged, and otherwise motivated into  
> trying to "fix the X11 problem in Macports" as well... so I figured  
> I'd make some proper introductions, and offer some suggestions to  
> see what everyone's thoughts are on the subject before I start  
> changing things only to have 100 people lash out at me for  
> "breaking" something... so here goes...
>
> 1) The dependency issue
>
> X11 lives in a grey area in Macports' dependency policy.  X11 is  
> actually given as the example for something that is appropriate to  
> use the lib:* or bin:* dependency rather than a port:* dependency,  
> yet there are plenty of ports that are still using a port:  
> dependency.  I believe this is mainly for things like libXrender  
> (rather than libX11) as a legacy of what was available in Tiger's  
> X11.  I'd very much like to use anything in /usr/X11/* over  
> installing a duplicate in /opt/local, and I'm sure others are in  
> the same boat.  I have seen a fair share of bug reports on xquartz- 
> dev that came about simply because the macports version didn't have  
> a fix that was in the system version or macports config files (eg:  
> for fontconfig) didn't match system configurations, so users were  
> wondering why some fonts weren't available in some programs.
>
> I intend to go through all the x11 related ports and update  
> dependencies to be lib: or bin: where appropriate instead of port:  
> (if a port is not nomaintainer or openmaintainer, I will file a bug  
> in trac to be on the safe side... unless general consensus here is  
> that such reports would be overkill and I should just do it myself)
>
> 2) The other dependency issue
>
> Now, for what port to actually depend on... Quickly grepping though  
> the code, I have seen the following dependencies for libX11:
>
> lib:libX11.6:XFree86
> lib:libX11.6:xorg
> lib:libX11:XFree86
> lib:libX11:xorg
> lib:libX11:xorg-libX11
>
> I'd like to standardize this to be xorg-libX11

We did have consensus and standardization: everything that needed X11  
declared a dependency on "lib:libX11.6:XFree86". Then some people  
started changing some ports to "lib:libX11.6:xorg" for an unknown  
reason.

As I understand it, the reason we have a policy exception to allow  
Apple X11 to be used instead of XFree86 or xorg in MacPorts is that  
Apple X11 integrates nicely with Mac OS X. I've never used xorg in  
MacPorts, but I tried installing XFree86 some time ago and when it  
launched, it had a weird cursor, weird window behavior, it launched 5  
weird-shaped and weird-colored terminal windows I couldn't figure out  
how to deal with, and it was just a very off-putting experience. I  
figured I didn't know what I was doing, uninstalled it, and returned  
to Apple X11 which always worked great.

My initial impression is that we shouldn't have a policy exception  
for everything Leopard's X11 provides, however. fontconfig, xrender,  
etc. are surely newer in MacPorts than they are in Tiger, and we  
still support Tiger, and some people even still use MacPorts on  
Panther. If there are things in Leopard's X11 that are newer than  
what we have in MacPorts, then let's update what we have in MacPorts.  
If a MacPorts port configuration (you say fontconfig?) doesn't  
integrate well with the OS, then let's fix that port.


> 3) The old monolith xorg and XFree86
>
> I'd like to eventually punt these in favor of having just one X11  
> solution in Macports based on the latest release.

I have no problem with changing the recommended non-Apple X11 from  
XFree8 to xorg for example. (I understand that Apple's X11 switched  
from being based on XFree86 to being based on xorg, and that would be  
a fine reason to also prefer xorg as the fallback in MacPorts.) If  
that's decided, then it should be done in all ports at once.  
Otherwise people are left wondering why some ports depend on one X  
implementation and others on another.

As long as both projects continue to exist and function on current  
OSes, there's no reason to delete one or the other, however, is  
there? Choice is a good thing, and we certainly have other cases of  
duplicate functionality in ports.