Versioned ports (again)

Boyd Waters bwaters at nrao.edu
Thu Mar 6 11:16:54 PST 2008


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







More information about the macports-dev mailing list