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. The only things that remain are selectively resyncing the branch with trunk and updating the proper License.html, ReadMe.rtf and postflight files in the files dir of the MacPorts port dir, for pkg installer creation. I plan to use svn:externals off of the release tag (once I create it) for the latter, rather than needlessly keep on duplicating those files across the repo. As for the former, selectively resyncing the release branch and trunk, I think there's nothing outstanding other than working out the differences between the postfight script on release and its trunk guise: on release we're still tweaking user shell configuration files and in trunk we're discussing James' additions to the /etc/[man]paths.d/ directories, so those two fronts will likely remain decoupled for the time being. There's also James' "load" & "unload" new port(1) targets, which James explicitly requested remain only in trunk until further tested (which rules out the merger of Ryan's r31771, which if I understand correctly is a regression fix against the new targets). Am I correct? Anything I'm missing? Thanks for your help in getting 1.6 out ASAP (it's been delayed enough already ;-). Regards,... -jmpp
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. FYI, modifying the .profile will not necessarily work with zsh (this is quite complex, see its man page). 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). -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
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
On Dec 7, 2007, at 1:38 PM, Juan Manuel Palacios wrote: (snip)
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.
(snip) In my r31818 edit to the postflight script in the release_1_6 brach I removed the globs that would match all C based shells and all bourne based shells, limiting our targets to only tcsh and bash specifically (again, we're only aiming to adapt for MacPorts a default OS installation).
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.
I haven't received any more feedback for this particular part of the script, so I'm going to (hopefully not wrongfully) assume that what we are doing now is indeed the lesser evil. Please speak up before it is too late if there is indeed something better we could do to fix the manpath situation. As for the rest before I finally release 1.6.0, I'm only concerned about http://trac.macosforge.org/projects/macports/ticket/ 13436#comment:5 Markus, IIRC prebinding does have its benefits on the Panther platform, so why not keep it there through a simple `if` statement? Or do we *also* want to remove all traces of prebinding for panther users? We could use something as simple as Kevin's "set os_major [lindex [split $tcl_platform(osVersion) .] 0]" for the $os.major variable in port1.0 to determine if we're on Darwin 7. Regards,... -jmpp
On 2007-12-07 13:38:26 -0400, Juan Manuel Palacios wrote:
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.
No, the user can have a $MANPATH while still being able to use the standard man paths. You should check that MANPATH doesn't contain an empty path. There are 3 cases: :path_list path_list: path_list::path_list (and of course the case where $MANPATH is empty). -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
participants (2)
-
Juan Manuel Palacios
-
Vincent Lefevre