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

[Juan Manuel Palacios]

On Dec 2, 2007, at 5:49 PM, Ryan Schmidt wrote:

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


	Yes, I agree 100% percent. But please do note that all the changes I  
merged into the release_1_6 branch since rc2, except for 2, have had  
nothing to do with MacPorts functionality. Mostly just with the  
PortIndex2MySQL script (after working with Bill to deploy it on Mac OS  
Forge), which, on the one hand, I've been testing locally extensively  
for a really long time and, on the other hand, is something most  
regular users never even see.

	Of the two commits that do have to do with MacPorts functionality:

*) one is a corner-case bugfix against the "dp2mp-move" upgrade code  
(paths with spaces embedded in them), which I satisfactorily tested, and
*) the other is the path munging work by James Berry, which I'm  
inclined to remove from the branch.

	There is yet a third functionality change I'm considering integrating  
into the release branch, but, again, it's just another bug fix  which  
I asked Anders to put together (through private mail), related to the  
pkg target (and a rather cosmetic issue for that matter).

	So all in all, I believe the spirit of RC has been respected.

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


	That's precisely the approach I favored in a previous post of mine to  
this thread.

	Regards,...


-jmpp