[38109] trunk/base

[Randall Wood]

On Mon, Jul 7, 2008 at 12:02 PM, Landon Fuller <landonf at macports.org> wrote:
>
> On Jul 7, 2008, at 3:18 AM, Randall Wood wrote:
>
>> On Mon, Jul 7, 2008 at 5:00 AM, Ryan Schmidt <ryandesign at macports.org>
>> wrote:
>>>
>>>
>>> Do you mean to change the user's shell for them? It should be possible
>>> with
>>> NetInfo. But I don't think MacPorts should be the one to tell the user
>>> what
>>> shell to use.
>>>
>>> Or did you mean something else?
>>>
>>>
>> I meant something like what fink does. See
>> http://trac.macports.org/wiki/SummerOfCode task 10
>
> I'm not sure I'd want ports to assume the ability to modify my shell
> environment.
> The shell environment something I'm pretty specific about, and I wouldn't
> want anything assuming that it could modify it.
>
> -landonf
>

In your case, you probably don't want to source a macports script for
your environment anyway, right?

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)

An ideal mechanism would be something like having a port include a
statement like:

shell.env name value

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

-- 
Randall Wood
randall.h.wood at alexandriasoftware.com

"The rules are simple: The ball is round. The game lasts 90 minutes.
All the rest is just philosophy."