*_select's

[Neil]

On 30 Nov 2008, at 01:19, Bryan Blackburn wrote:

> On Sat, Nov 29, 2008 at 11:34:11PM -0600, Ryan Schmidt said:
>>
>> On Nov 29, 2008, at 16:50, Neil wrote:
>>>
>>> After thought: Maybe we should consolidate all the *_selects in
>>> something akin to eselect on Gentoo?
>>
>>
>> For those of us not familiar with gentoo, how does eselect work?
>
> I haven't used gentoo, but perhaps it's something along the lines of  
> what
> I've thought we should do with the _select stuff: instead of  
> abc_select,
> xyz_select, etc, just have a select/port_select/macports_select  
> (whatever we
> decide to call it) and instead have the first argument be the system
> affected, then the second the version to select.  Instead of
>
> $ python_select python25
> $ gcc_select mp-gcc43
>
> it would just be
>
> $ select python 2.5
> $ select gcc mp-4.3
>
> The ${prefix}/etc/select stuff is already subdivided by system like  
> this, so
> it should be a pretty natural change, though the arguments will  
> obviously be
> a bit different.
>
> Bryan


(Maybe this should move to macports-dev?)

Yeah, basically.  Instead of having a "gcc_select" manage gcc  
symlinks, and a "python_select" manage python symlinks, we could have  
a "port_select" or "portver_select" or <name of choice>, and it would  
manage symlinks for everything with multiple versions.  The main  
advantage is cutting down on redundant code, ensuring a consistent  
interface, and making it easier to have more select-able ports.

I think, ideally, we'd have a tree (which we seem to already have):
	select/portname/(variant|version).conf
Each variant should install their own, I think, just to keep stuff  
together.

And that would just contain some pairs of files (which seems different  
from the current file format):
	realfile1		symlink1
	realfile2		symlink2
And when we pick one, we just go and remove all the symlinks from the  
old, and add all the new ones.  (We'll keep track of which is  
"current" somewhere.)

The current format seems to have just split the one file I'm proposing  
above into two files, one called "base" and the other based on name,  
and just matches lines from one to the other, if I'm not mistaken.   
The disadvantage to this that I see is that base file must hold a line  
for every possible place the package might want to put something; and  
it seems like errors and mix-ups can be induced somewhat easily.

While we're at it, it would be nice if there was a clearer way to  
select the built-in versions of some of these ports (ie. if I want to  
use my non-MacPorts Python, it's python25-apple; but if I want to use  
the built-in gcc, it seems to be gcc40...it doesn't seem clear to me  
that there's a convention).

-N.