Added support in MacPorts base to set PATH and MANPATH automatically in Leopard

[Bjarne D Mathiesen]

Juan Manuel Palacios wrote:
> 
> On Nov 30, 2007, at 1:00 PM, Bjarne D Mathiesen wrote:
> 
>> How about this:
>>
I'll amend with this:
cp -n /etc/paths /etc/paths.orig
>> mkdir -p /etc/paths.d
>> mv -n /etc/paths /etc/paths.d/999macosx
>> touch /etc/paths
>> echo "${prefix}/bin" > /etc/paths.d/000macports
>> echo "${prefix}/sbin" >> /etc/paths.d/000macports
>> echo "/Developer/Tools" > /etc/paths.d/888developer
>>

cp -n /etc/manpaths /etc/manpaths.orig
>> mkdir -p /etc/manpaths.d
>> mv -n /etc/manpaths /etc/manpaths.d/999macosx
>> touch /etc/manpaths
>> echo "${prefix}/share/man" > /etc/manpaths.d/000macports

These two cp commands will keep a backup copy of the original files

>>
>> If the paths are loaded in alphabetical order, this ought to ensure that
>> the macports paths are before the standard Mac OS X ones.
>>
>> You _do_ want the macport path to be before the standard paths as I
>> guess you want to execute the alternative utilities provided by macports
>> instaed of those from Mac OS X ;-)
> 
> 
>     Even though prepending our path settings to the environment (rather
> than appending them) is what is preferred and what has been proven to
> work more smoothly, a hack like what's being proposed above makes me
> very uncomfortable. Maybe I'm not sufficiently acquainted with its
> simplicity, but a mere glance makes me fearful of many things we could
> potentially be breaking. Actually, for that matter, the simple thought
> of changing anything in /etc/ is not something I'm not too happy with;
> for me that's a "hands off" area of the system... but I'm aware that's
> another discussion.

Actually, if I understand the situation correctly, the (man)paths.d
dirctories _are_ meant to be modified by the sysadmin

> 
>     So, has any conclusion been reached for this issue? I'm inclined to
> backing this feature out of the release_1_6 branch until a working
> consensus is reached, and only release it to the public at that time (in
> 1.6.x (x > 0)). Until now we've only been modifying the user "profile"
> for a range of bourne based shells and the "cshrc" file for equivalent C
> based shells, which has worked fairly well, I believe; anyone
> experienced enough to create something like ~/.bash_profile or anything
> else very shell specific would be savvy enough to setup his/her own
> environment to their content, I'm sure. I'd strongly favor sticking to
> this approach in 1.6.0 until something better is found, unless it
> explicitly breaks expected behavior on Leopard. Does it?

I'm much more unhappy with the proposal for modifying a user's
~/.bash_profile (or the equivalent for other shells)

1) you'll have to test for and modify each and every of these files
instead of doing it once at the system level

2) I regard the ~/.bash_profile as a hands-off file much more so than
files at the system level. When you install something you _should_
expect that something might change at the system level. But messing
around with someone's personal settings ... nope

3) you'll only get it done for the user installing macports. Other users
won't get the benefit.

4) we can insert comments in the files we install/modify and use these
comments to back out our changes

5) the script I've provided can be run as many times as you want without
breaking anything.

> 
>     Regards,...
> 
> -jmpp
> 

-- 
Bjarne D Mathiesen
København N ; Danmark ; Europa
----------------------------------------------------------------------
denne besked er skrevet i et totalt M$-frit miljø
MacOS X 10.5.1 Leopard ; Seamonkey 1.1.x ; PowerPC G4 800MHz