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