Randall Wood wrote: > But if you are going to source some script we provide, why not let > ports set certain expected environment variables that make > correct-in-most-cases-but-not-ours assumptions that can be overridden > by setting the environment. Its better than patching the upstream code > if the code respects env. variables, and carries defaults that make > sense in almost every other UNIX out in the wild. (Specifically, I am > thinking of the environment variables that unless set or patched, > cause GNOME/KDE/other-Freedesktop-spec-implementations to look for > configuration data in /usr or /usr/local instead of /opt/local)
Software installed by MacPorts always looks in /opt/local. Exporting some variables could cause software from /usr/bin to look in /opt/local, too. This might be unexpected and not so easy to track down for users when they are not aware of these variables. > An ideal mechanism would be something like having a port include a > statement like: > > shell.env name value Can you provide example ports we currently have in the tree which would benefit from such a mechanism? > and having the install/uninstall phases generate/remove a file (1 for > each supported shell environment) containing the shell-specific syntax > for including that variable in the shell uninstall/deactivate hooks were planned for registry2.0, but there is no ongoing development on this. I sent a status request to Chris some time ago... Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
