Re: [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 <[EMAIL PROTECTED]> wrote:

On Jul 7, 2008, at 3:18 AM, Randall Wood wrote:

On Mon, Jul 7, 2008 at 5:00 AM, Ryan Schmidt <[EMAIL PROTECTED] >

wrote:

with

what
shell to use.

Or did you mean something else?

Do you mean to change the user's shell for them? It should be possible NetInfo. But I don't think MacPorts should be the one to tell the user

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.

want anything assuming that it could modify it.

-landonf

The shell environment something I'm pretty specific about, and I wouldn't

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

-landonf

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.

PGP.sig
Description: This is a digitally signed message part

_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev