Clarify policy of duplicating ${x11prefix}

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

xrender was recently upgraded (r42693).
This was good for Leopard users but bad for Tiger users because
it seemingly didn't like the XFree86 base (#17429).

MacPorts allows the Apple X11 to be used (and rightly so).
I think we need to make a clear distinction between the parts of
${x11prefix} which are subject to the MacPorts policy of ​using its own libraries and which are not.

Just off the top of my head, for example:

Component ${x11prefix}	Require Duplication
libX11.dylib	No
xrender	No (based on #17429)
libpng	Yes
libcairo	Yes
fontconfig	??? (there was an issue mentioned in the ​mailing list)
glut	???

The good people at ​XQuartz have (and are) doing a fine job of getting X to run on Macs.
It would seem a shame to either try to reproduce or ignore their work.

Perhaps the test should be:
If the component in ${x11prefix} offers an improvement (e.g. better Quartz integration) do not require duplication.

There was a ​discussion related to this issue, but it is a little unclear if any consensus was reached.

In the short term, I wanted to know how people felt about changing xrender dependencies to lib:libXrender:xrender.

[jeremyhu (Jeremy Huddleston Sequoia)]

I agree, but there might be some ports that need a newer libXrender than is provided by Tiger's X11's libXrender...

[jeremyhu (Jeremy Huddleston Sequoia)]

I'd say fontconfig should definitely be a "No"... but maybe we should discuss that on the list a bit more... Many a user have complained on xquartz-dev about fonts not working right and it boiled down to their macports fontconfig...

[ryandesign (Ryan Carsten Schmidt)]

I'd say fontconfig should definitely be a "yes" because fontconfig in MacPorts is newer than fontconfig on Tiger. If fontconfig in MacPorts doesn't work right, file a ticket against it.

[jeremyhu (Jeremy Huddleston Sequoia)]

I think it should be Yes for Tiger, but no for Leopard and later.

What doesn't work right about it is that it uses a completely separate configuration file and that won't be fixed.

[ryandesign (Ryan Carsten Schmidt)]

The reason for our policy of using MacPorts versions instead of Apple versions is so that we can keep it up to date. Or can you guarantee a change in Apple policy, that Apple will always keep its libraries up to date from now on?

What is the matter with the MacPorts freetype configuration file? In any case, this discussion is not relevant in this ticket, so please either file a new one, or bring it up on the mailing list.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to ryandesign@…:

The reason for our policy of using MacPorts versions instead of Apple versions is so that we can keep it up to date. Or can you guarantee a change in Apple policy, that Apple will always keep its libraries up to date from now on?

I see your point, but it seems to me that we do rely on Apple software even though Apple makes no guarantees about how recent it is.
X11 and gcc being the big ones.
It seems that some ports are so closely tied to X11 that it is not a good idea to try to separate them out.
Perhaps xrender and fontconfig are such ports.

What is the matter with the MacPorts freetype configuration file? In any case, this discussion is not relevant in this ticket, so please either file a new one, or bring it up on the mailing list.

There was some confusion on my part as to what the X11 policy should be, which is why I opened the ticket.
It seemed like a good forum to hash some of these issues out.
If others think that the mailing list is better, then that is fine.

[jeremyhu (Jeremy Huddleston Sequoia)]

I brought this up a few times in macports-dev (most recently today with a patch for a system_x11 variant which results in our use of ports for X11 libs rather than $x11prefix).

I'm closing this as 'invalid' since it's not really a bug but rather a policy that needs to be worked out on the list.

[(none)]

Milestone Port Bugs deleted