moving "macports1.0" to ${prefix}

[Blair Zajac]

Landon Fuller wrote:
> 
> On Aug 16, 2007, at 10:55, Blair Zajac wrote:
> 
>> Landon Fuller wrote:
>>> On Aug 16, 2007, at 02:15, Anders F Björklund wrote:
>>>>
>>>> For MacPorts 1.6, it might be a good idea to consider moving 
>>>> "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the 
>>>> @prefix_expanded@/share/macports/Tcl directory, in order to make the 
>>>> MacPorts installation self-contained within the designated prefix ?
>>>>
>>>> If the "macports1.0" module needs to be in the system's Tcl package 
>>>> directory in order for other (inferior) software to find it, then 
>>>> can't this be accomplished by setting up a symbolic link ? e.g. 
>>>> /Library/Tcl/macports1.0 -> /opt/local/share/macports/Tcl/macports1.0
>>> I'll register a "please, no!". The whole point of putting macports in 
>>> /Library/Tcl/macports1.0 was to support "inferior" software that 
>>> needs to be able to find the system's macports installation, 
>>> regardless of ${prefix}.
>>
>> What software is this?
> 
> Any third party tool that rightfully expects "package require macports" 
> to work.

I'm just trying to get a sense of what we're talking about here, as we're 
discussing trade offs between competing concerns.

How many tools are out there?  I haven't used any of them, what are their names?

How does that third party software even work if I do a --with-tclpackage?  Does 
it break?

What about getting the third-party software to work with multiple MacPorts 
installs?  How does that work?

It sounds like the third-party software should grow support to handle multiple 
MacPorts installs and the ability to point it at the root of an install and be 
able to find the TCL files it needs.

Right now with --with-tclpackage, if everybody puts them into their own path 
under $prefix, then there's almost no hope for the third-party software.  If we 
standardize on a location in $prefix, then the user can point the software at a 
MacPorts install and except it to work.

So one remaining issue is how to get the third-party software to easily pick up 
the TCL files from a MacPorts install.  It could check for a default location in 
/opt/local.  Maybe use an environmental variable MACPORTS_HOME.

>> The use case for having multiple MacPorts is fairly common.
> 
> Amongst developers. Not users. Most users have one installation of 
> MacPorts.
> 
>>
>> We have three +1's for making the change.  Should we have a vote?
> 
> Because direct democracy is the best method for making technical decisions?

We have votes in the Subversion project on technical discussions, nothing new there.

Regards,
Blair