Final steps for 1.6

[Juan Manuel Palacios]

On Dec 7, 2007, at 4:53 AM, Vincent Lefevre wrote:

> On 2007-12-07 00:17:04 -0400, Juan Manuel Palacios wrote:
>> 	My list of outstanding TODOs for the 1.6 release is almost empty  
>> after
>> finishing what I committed  in r31774, directly to the release  
>> branch: a
>> rethought and rewritten postflight script to add PATH and MANPATH
>> settings as appropriate to the user's shell configuration file.  
>> Please
>> read the commit log and test the script, reporting any findings  
>> you have.
>
> When will this be modified exactly? There's should be a confirmation
> from the user in any case.


	The script is run by Installer.app after the bundled package is  
installed (hence "postflight"). We don't currently add an explicit  
warning sheet with an "OK" dismissal button alerting users as to what  
we're about to do, but we do certainly explain it as openly as  
possible in both our website and in the ReadMe.rtf file that  
introduces you to the Installer.app package. I agree such sheet would  
be a good addition, though, so pointers on how to do it are welcome.  
Anders, any idea on how to get something akin to the "this package  
needs to run a program" warning sheets that we see in some  
Installer.app packages?

>
> FYI, modifying the .profile will not necessarily work with zsh  
> (this is
> quite complex, see its man page).


	Thanks for bringing this up! The original intent of the postflight  
script was only to make life easier for non-savvy users who didn't  
have much of an idea on how to adapt their shell files to work with  
MacPorts. The key aspect to that statement is "non-savvy users", and  
personally I believe that anyone savvy enough to change his/her shell  
to zsh is also savvy enough to manually adapt his/her environment as  
needed. Since our target audience for this postflight script is  
likely to stick to default settings, I wouldn't have a problem with  
limiting the scope of this script to the bash shell, as that's what's  
default from Panther onward. We could by extension include tcsh, who  
knows, but the point I'm trying to make is that I'm personally not  
that comfortable either with the *sh glob that matches zsh and many  
others at $CONF_FILE selection time:

USHELL=$(basename $SHELL)
case $USHELL in
     *csh)
         CONF_FILE=.cshrc
         ;;
     *sh)
         CONF_FILE=.profile
         ;;
     *)
         echo "Unknown shell! Please set your MacPorts compatible  
environment manually."
         ;;
esac



	Thoughts?

>
> Also, it's a bad idea to modify $MANPATH as this may break things in
> particular if the user usually has an empty $MANPATH (in which case
> the man path is automatically built from $PATH -- this is much better
> to get consistent paths).


	Adding our setting to MANPATH *only-if-it-already-exists* *and* if  
we're not already in there was agreed here to be the "lesser evil"  
for the time being, so that's what we're doing. If MANPATH does not  
exist at all (different from existing but being empty, or otherwise  
not containing our path), we don't add anything there and instead let  
alternative methods to their work (manpath(1), path_helper(8),  
whatever). If MANPATH exists (thus probably overriding the work of  
those alternate methods), and does not contain our path, then (and  
only then) we add it. If I'm not mistaken, having an *existing*  
MANPATH variable that does not contain our path is precisely the  
situation that breaks our man pages and what we're trying to remedy.

	Needless to say, I'm more than open to any other better approach  
going forward (yes, most probably meaning that what we now have for  
1.6 will be frozen to substantial changes -- that is, anything other  
than bug fixes).

	Regards,....


-jmpp