moving "macports1.0" to ${prefix}

[Landon Fuller]

On Aug 16, 2007, at 12:10, Blair Zajac wrote:

>>> I'm just trying to get a sense of what we're talking about here,  
>>> as we're discussing trade offs between competing concerns.
>> OK, then I'll simplify.
>> Arguments For Moving:
>>     Developers can install multiple versions without passing -- 
>> with-tclpackage to configure (but they still have to pass a custom  
>> --prefix to configure)
>> Arguments Against Moving:
>>     Placing the Tcl package in the standard Tcl package directory  
>> means that external tools can find the system MacPorts library out  
>> of the box.
>> It seems to me like developers already have an easily solution to  
>> their problem.
>> -landonf
>
> I got these points.
>
> Can you address the rest of the questions I asked in the previous  
> note?  That'll provide more context to make a choice.

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

Don't know. How many tools and custom code out there uses zlib?

The choice was originally made to support the GUI PortsManager app. I  
think it was a good choice.

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

It would break unless the author endeavoured to support your non- 
standard Tcl package installation.

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

See answer above.

> 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.

Except that nobody, other than developers, will be running multiple  
MacPorts installations. You're taking a simple fix to a simple problem:
	- Install MacPorts in the standard Tcl library directory, where  
external software can access it.

And proposing a complex fix for a non-existent problem:
	Developers don't have to type an extra --with-tclpackage, and users  
have to set MACPORTS_HOME and tell any external software where to  
find the MacPorts installation

I hold that this is an entirely aesthetically-driven bike shed.  
Unless there's a *really good reason* to change something, why don't  
we just leave it, and the original logic behind it, alone?

> 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.

Setting environmental variables in the GUI is beyond the scope of  
most user's needs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070816/2f5adb8e/PGP.bin