[38109] trunk/base

[Landon Fuller]

On Jul 7, 2008, at 9:41 AM, Randall Wood wrote:

> 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

Ports would assume those environmental variables are set (and can be  
set), rather than patching the software and having it Just Work no  
matter what environment they're run from (including non-shell  
environments).

I'd say patching is a lot less complicated, and far more polite, than  
trying to control the program's external environment.

-landonf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080707/22538f67/attachment.bin