#17453: Clarify policy of duplicating ${x11prefix} -----------------------------------+---------------------------------------- Reporter: mcalhoun@… | Owner: mcalhoun@… Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: | Port: -----------------------------------+---------------------------------------- xrender was recently upgraded (r42693).[[BR]] This was good for Leopard users but bad for Tiger users because[[BR]] it seemingly didn't like the XFree86 base (#17429). MacPorts allows the Apple X11 to be used (and rightly so).[[BR]] I think we need to make a clear distinction between the parts of[[BR]] ${x11prefix} which are subject to the MacPorts policy of [http://trac.macports.org/wiki/FAQ#WhyisMacPortsusingitsownlibraries using its own libraries] and which are not. Just off the top of my head, for example:[[BR]] ||Component ${x11prefix} || Require Duplication|| ||libX11.dylib || No || ||xrender || No (based on #17429) || ||libpng|| Yes || ||libcairo|| Yes || ||fontconfig || ??? (there was an issue mentioned in the [http://lists.macosforge.org/pipermail/macports- dev/2008-November/006454.html mailing list])|| ||glut || ??? || The good people at [http://xquartz.macosforge.org/ XQuartz] have (and are) doing a fine job of getting X to run on Macs.[[BR]] It would seem a shame to either try to reproduce or ignore their work. Perhaps the test should be:[[BR]] If the component in ${x11prefix} offers an improvement (e.g. better Quartz integration) do not require duplication. There was a [http://lists.macosforge.org/pipermail/macports- dev/2008-November/006454.html 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. -- Ticket URL: <http://trac.macports.org/ticket/17453> MacPorts <http://www.macports.org/> Ports system for Mac OS