Added support in MacPorts base to set PATH and MANPATH automatically in Leopard

[Ryan Schmidt]

On Dec 2, 2007, at 12:35, Juan Manuel Palacios wrote:

>> 	(2) Supplement this scheme by munging PATH inside the MacPorts  
>> code to ensure that $prefix is always at the head of the path  
>> during builds, and to guard against the sort of build problems  
>> suggested by kvv.
>
> 	MacPorts already sets its internal path for a few things, so this  
> suggestion may be easy to implement but might, just might, have  
> repercussions that we may want to test more thoroughly (not on the  
> verge of a release, in my opinion ;-)

Yes, just to chime in a bit on that point: I'm rather unhappy about  
all these changes that appear to be going into 1.6.0 after we've  
already had two release candidates. That's not what release candidate  
means. Release candidate means that it is a candidate for release,  
and if no major problems are found, it will be released as is. It  
does not mean that we will add lots of other code and then release  
it, especially not with another release candidate. I don't want  
another MacPorts 1.4.0--no wait, 1.4.1--no wait, 1.4.2--no wait,  
1.4.3. That's exactly what release candidates are supposed to prevent.

Ok, if the manpages aren't working on Leopard because of this, then  
we could fix it. On the other hand, it's equally broken in all  
previous versions of MacPorts, so we're not introducing any  
additional breakage, which is what I'm most interested in. New  
releases of MacPorts should only improve things. Even a little  
improvement at a time is fine. Introducing major changes to how key  
parts work, right before a new release of MacPorts, is not to my liking.

So my suggestion would be to either leave the path setup the way it  
is in 1.5.2, let it continue to be broken in Leopard, and think about  
how best to fix it after release, or to take the (I hope) simpler  
route of munging MANPATH in addition to PATH, only if MANPATH is set.