[38109] trunk/base

[Rainer Müller]

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