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

[Juan Manuel Palacios]

	Hello Marc!

On Dec 3, 2007, at 7:28 AM, Marc André Selig wrote:

> Let me start out by saying I find this whole business of modifying
> users' files without telling them so quite awkward.


	Please note that all this path & manpath munging, user specific  
against system wide files modification is only meant to happen from  
the pkg installer (off of its postfligth script located in svn's base/ 
portmgr/dmg) which:

*) Does warn users in the welcoming ReadMe.rtf file displayed by the  
installer that their environment will be modified for MacPorts usage;
*) As it is aimed at a group of users who either don't want or don't  
know how to install from source, it is configured in the most standard  
fashion possible and, as such, it is only meant to work in that  
situation. If you're experienced enough to modify your system in  
meaningful ways, such as placing your profile file in a read-only  
image, then surely you're savvy enough to install from source and  
setup your own MacPorts environment (no project at all can afford to  
construct hand-holding installers of their software and instructions  
for more than a bare couple of usually similar-among-them scenarios).  
This is also made clear througout the documentation: ReadMe.rtf,  
website, guide, etc.

	If you feel we're still not being clear and forthcoming enough about  
this scenario and assumptions we're presenting the user with, then  
please feel most free to suggest improvements anywhere you might find  
them appropriate.

>
>
> On Dec 3, 2007 6:14 AM, Juan Manuel Palacios <jmpp at macports.org>  
> wrote:
>> *sh)
>>       if $SHELL -lc "/usr/bin/env | grep -q MANPATH" && ! $SHELL - 
>> lc "/usr/
>> bin/printenv MANPATH" |  grep -q /opt/local/share/man; then
>>               echo "export MANPATH=/opt/local/share/man:\$PATH" >>  
>> $HOME/.profile
>>       fi
>
> This would fail silently on my account, where ~/.profile is symlinked
> to a read-only image under normal circumstances.


	This is a new instruction that would print further content into the  
profile file, yes. But note that overall behavior is unchanged: if  
that fails for you, then the entire postflight script fails because  
prior to that there are also other instructions printed to the  
profile. Your "bug report" is not applicable, I'm afraid to say, the  
postflight script is simply not meant to work with your setup.  
Nevertheless, as I said above, please feel most free to suggest any  
improvements you might find appropriate, like some welcomed error  
catching.


> If you don't catch
> the error, things would go from "it fails unless you do everything in
> the documentation" to "it fails if you do the things in the
> (shortened) documentation; read the source if you want to get it
> working again".


	What documentation are you referring to? What's the shortened version  
that's leaving you in a rather lost state?


> I clearly prefer the old variant (more things to do,
> but if you do them all, things work) to the new one (it works
> magically if your installation is pure standard, but fails in
> mysterious ways otherwise).


	There is no old and new way. We've had this postflight script for a  
long time already and all we're doing now is enhancing it to fill  
avoid we're encountering on Leopard (an appropriate setting for  
MacPorts installed man pages). James' enhancements writing to /etc/ 
[man]paths.d/ were deferred because they are not yet polished enough  
for production time, so we're aiming for this alternative through the  
same postflight script that, if it doesn't work for you now because of  
the setup you describe, it simply couldn't have worked for you earlier  
either.

	Also, magically working on a pure standard scenario but failing  
unexpectedly on different ones is precisely what the pgk installer and  
its postflight script are meant to do, that's expected behavior. If  
you're on the latter crowd, then please install from source. We as a  
team have not discussed putting together binary installers to cover  
for other scenarios than the pure standard one. I'm not saying we  
*wont* do it, but rather that we simply haven't; if we do, then I'm  
sure mixing its settings/considerations/assumptions with the ones of  
the pure standard scenario would be a very bad approach. In such case  
we'd be building two or more completely different and separate  
installers, each with its own private set of resources.

>
>
> Just the point of view of a mere user. :-)


	And appreciated! Would love to study whatever enhancement you might  
propose.

>
>
> Regards,
> Marc
>
> PS: I agree that modifying the local user's preferences is preferrable
> to modifying /etc.  I still think it needs to be pointed out quite
> clearly in the installation manual (i.e. you don't get to shorten the
> manual if you do this).  Otherwise, everybody who has one account for
> each user (plus one account for managing the machine) will not know to
> add your stub to the .profile of each user who wants to use MacPorts.


	Those are interesting documentation enhancements, making it clear  
that the environment we're setting up will only work on a per user  
basis.

>
>
> PPS: Another story from the point of view of a mere user: I've had
> people apparently locked out from their machine because they had
> /opt/local/bin first thing in their PATH and some port had pulled in a
> version of sudo that did not work.  I've been telling people to put
> /opt/local/bin at the end ever since.


	That should definitely be filed as a bug in our Trac. In fact I think  
it was and I also think it was fixed, but I don't have any reference  
to that, sorry.

	Regards,...


-jmpp