X11 in Macports

[Jeremy Huddleston]

Oh and one more issue I just remembered... I've seen quite a few ports  
do:

prefix ${x11prefix}

This seems to be a clear violation of the "nothing in /usr" policy...  
and as someone who feels some amount of ownership of /usr/X11, I don't  
want to see it get potentially thrashed...

Am I correct in assuming that this is flat out wrong and should be  
reverted back to installing into the macports dstroot?  Or was there  
some reason for doing this that I'm not seeing?


On Nov 22, 2008, at 21: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.  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
>
> 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.
>
>
>
> Thoughts?
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev