On Thu, Aug 15, 2013 at 2:07 AM, Ryan Schmidt wrote: > If possible, ports should not conflict. The way to make them not conflict is > not to try to install the same file to the same location from multiple ports. > Rename the files or install them to different locations. > > There may be places in the code of the project where the files are referenced > by name or location which would have to be patched to accommodate the rename > or move. And if it is a public file that other ports are expected to use, > then that magnifies the problem since they all would need to know about the > rename or move as well.
I inspected the situation a bit. (1) First about the conflict between py26-* and py27-* (an ancient ticket is here for example: https://trac.macports.org/ticket/19190). They seem to install exactly the same files to exactly the same location (header files, swig interface, python files, ... - all just literal copies from the sources). I can resolve the conflict by: - manually copying (a nontrivial subset of the files) from sources when installing the main py-* port - deleting these files in post-destroot phase of py2X-*. - making py-* a dependency of py2X-*. It will be ugly and I'm not sure that many users really need that functionality (at the moment py26-wxpython30 doesn't even exist), but if that's desirable, I can do it. An alternative is to make the port provide just "python.versions 27" ;) which is what it does now and only implement that ugly hack if py28 or py33 will ever be needed. Or maybe do this just for wxPython 2.8 which currently provides support for four versions of python. (2) About the conflict between wxPython 2.8 and 2.9: I didn't inspect closely yet, but this seems a bigger problem. Most probably because users simply do import wx inside the python sources and I have no clue how to tell python that a different version of "wx" should be used. The easiest workaround is probably to install py27-wxpython-3.0 and py26-wxpython-2.8 which means that wxWidgets 2.8 would be used with Python 2.6 and wxWidgets 2.9 would be used with Python 2.7. But maybe someone else can enlighten me by pointing out a possible solution. Mojca _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
