• because we change lib/python2.5 from a directory into a symlink. Otherwise you will see errors with file_map.db. • Because of the directory-to-symlink change, deactivate/activate does not work. This will be the main challenge.

I think that this is why I haven't committed anything; I've been building all Python 2.5 stuff via MacPorts as a framework build for about a year now. I had to modify all of my Python ports that I use so that they understand the symlink. I attempted to modify MacPorts Tcl so that it would not die as it attempted to traverse a symlink, but I failed. I must not understand Tcl very well. I am pretty sure I don't understand all the issues, I still think that MacPorts versioning (-24, -25, -30) is profoundly flawed, aside from installation issues. But I'd be happy to show my awful hacked-up Python ports... - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory Socorro, New Mexico On Mar 6, 2008, at 11:00 AM, Rainer Müller wrote:

Hi Thomas,

Following the IRC discussion from today with afb and mdickens, I wrote together a wiki page which documents how we want to do the transition to build pythonXX as frameworks.

http://trac.macosforge.org/projects/macports/wiki/PythonFrameworkTransition

Any comments so far?

Also see the new branch at branches/python-frameworks. I already committed the efforts from #11267 there. With the branch, we can easily test the transition code.

Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Rainer: Thanks for the clarification! Ah, I see... put things in the portgroup. Of course... On Mar 6, 2008, at 11:48 AM, Rainer Müller wrote:

...

I am pretty sure I don't understand all the issues, I still think that MacPorts versioning (-24, -25, -30) is profoundly flawed, aside from installation issues.

Do you have any other solution? This is a bit unrelated to the framework transition. Multiple versions of the same software also apply to gcc and perl.

Well, I don't want to kick over old sand, but I came to MacPorts after years of Gentoo on Linux. It may not seem like a big deal to have some port dirs with versions, and some without, but I find it quite difficult to manage. I prefer having the Port *files* have versions. The way MacPorts manages the *installation* of gcc versions is fine: * specify a trailing version specifier on the files or dirs that get installed: for example gcc-mp-4.2 * provide a "packagename-select" utility to modify symlinks that point gcc -> gcc-mp-4.2 (among other things) Gentoo also had this notion of "provides" and "slots". I haven't used Gentoo for a while, so I'm trying to think of an example relevant to MacPorts. Well, I know that the Python Tkinter port has a variant to use the system (OS X-provided) Tk, rather than a MacPorts one. Another example might be X11 packages, or GCC (Apple 4.x versus MacPorts 4.x) -- the idea that a port dep can be satisfied by something that occupies a certain "slot" or "role", rather than a specific file at a specific location. So the GCC 4.x dependency could be satisfied by either Apple's or MacPort's package. Not a great example, perhaps someone else can help explain. But I don't think it's OK to add a specific version number to each port dir, without some notion of "slot". Port groups are some of that, but upside-down, as every leaf-level port needs to be aware of a particular port group. For example I've been hacking through the Python ports on Leopard, teaching them about the Apple-supplied Python 2.5.1... I added a port group "python-25-apple" to make that happen, but now I need to touch *every* python port and change their port group membership. In this case, it isn't a version: both the MacPort and the Apple Pythons are 2.5.1. It's something else, and the leaf- level ports should NOT have to know about that. I felt comfortable contributing Gentoo ports, because I could add versions or whatnot without changing the whole framework, and it was easy to drop something in. I have been quite nervous about perturbing the MacPorts, because if I have a different notion of Python deployment (for example) then that's too destructive, the framework has to be changed a bit to accommodate that, and certainly not everyone is going to want to do it my way. But I can't provide easy hooks to switch between my way and the default way. I hope these comments help. I suspect they won't make any sense to people who haven't used Gentoo much. It's not the same thing as the FreeBSD ports tree. Thanks! - boyd Boyd Waters http://www.aoc.nrao.edu/~bwaters