[MacPorts] #17453: Clarify policy of duplicating ${x11prefix}
#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
#17453: Clarify policy of duplicating ${x11prefix} -----------------------------------+---------------------------------------- Reporter: mcalhoun@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: | Port: -----------------------------------+---------------------------------------- Changes (by jeremyhu@…): * owner: mcalhoun@… => jeremyhu@… Comment: I agree, but there might be some ports that need a newer libXrender than is provided by Tiger's X11's libXrender... -- Ticket URL: <http://trac.macports.org/ticket/17453#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#17453: Clarify policy of duplicating ${x11prefix} -----------------------------------+---------------------------------------- Reporter: mcalhoun@… | Owner: jeremyhu@… Type: defect | Status: assigned Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: | Port: -----------------------------------+---------------------------------------- Changes (by jeremyhu@…): * status: new => assigned Comment: 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... -- Ticket URL: <http://trac.macports.org/ticket/17453#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#17453: Clarify policy of duplicating ${x11prefix} -----------------------------------+---------------------------------------- Reporter: mcalhoun@… | Owner: jeremyhu@… Type: defect | Status: assigned Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: | Port: -----------------------------------+---------------------------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) Comment: 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. -- Ticket URL: <http://trac.macports.org/ticket/17453#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#17453: Clarify policy of duplicating ${x11prefix} -----------------------------------+---------------------------------------- Reporter: mcalhoun@… | Owner: jeremyhu@… Type: defect | Status: assigned Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: | Port: -----------------------------------+---------------------------------------- Comment(by jeremyhu@…): 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. -- Ticket URL: <http://trac.macports.org/ticket/17453#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#17453: Clarify policy of duplicating ${x11prefix} -----------------------------------+---------------------------------------- Reporter: mcalhoun@… | Owner: jeremyhu@… Type: defect | Status: assigned Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: | Port: -----------------------------------+---------------------------------------- Comment(by 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? 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. -- Ticket URL: <http://trac.macports.org/ticket/17453#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS
#17453: Clarify policy of duplicating ${x11prefix} -----------------------------------+---------------------------------------- Reporter: mcalhoun@… | Owner: jeremyhu@… Type: defect | Status: assigned Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: | Port: -----------------------------------+---------------------------------------- Comment(by mcalhoun@…): Replying to [comment:5 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.[[BR]] X11 and gcc being the big ones.[[BR]] It seems that some ports are so closely tied to X11 that it is not a good idea to try to separate them out.[[BR]] 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.[[BR]] It seemed like a good forum to hash some of these issues out.[[BR]] If others think that the mailing list is better, then that is fine. -- Ticket URL: <http://trac.macports.org/ticket/17453#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS
#17453: Clarify policy of duplicating ${x11prefix} ------------------------------------+--------------------------------------- Reporter: mcalhoun@… | Owner: jeremyhu@… Type: defect | Status: closed Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Resolution: invalid | Keywords: Port: | ------------------------------------+--------------------------------------- Changes (by jeremyhu@…): * status: assigned => closed * resolution: => invalid Comment: 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. -- Ticket URL: <http://trac.macports.org/ticket/17453#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (1)
-
MacPorts