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

[Randall Wood]

Oops. Hit reply instead of reply all...

---------- Forwarded message ----------
From: Randall Wood <randall.h.wood at alexandriasoftware.com>
Date: Dec 2, 2007 3:41 PM
Subject: Re: Added support in MacPorts base to set PATH and MANPATH
automatically in Leopard
To: Juan Manuel Palacios <jmpp at macports.org>



On 12/2/07, Juan Manuel Palacios <jmpp at macports.org> wrote:
>
>
> On Dec 2, 2007, at 2:06 PM, James Berry wrote:
>
> > Hi Juan,
> >
> > On Dec 2, 2007, at 9:50 AM, Juan Manuel Palacios wrote:
> >>      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?
> >
> > Well, given that man pages are broken at present with a standard
> > MacPorts install under Leopard, something has to be done. A few
> > choices:
> >
> >       (1) Use this scheme, as implemented. (Downsides: affects /etc,
> > MacPorts paths are added at the end of PATH and MANPATH).
>
>
>         I'm uncomfortable with this approach, as already noted in my
> previous
> mail.



If Apple provides a mechanism for third-party developers to append paths to
PATH and MANPATH without changing any user or system-installed file, then I
think we should use it. We may want though (if this would work--I don't know
if symlinks would be honored or if only real files would be honored by this
mechanism) to use symlinks from /opt/local/etc/[man]path.d/macports to
/etc/[man]path.d/macports instead of placing files in /etc/[man]path.d and
provide a simple tool (like macports-path-util) to allow users to add/remove
those symlinks

>
> >
> >       (2) Supplement this scheme by munging PATH inside the MacPorts
> code
> > to ensure that $prefix is always at the head of the path during
> > builds, and to guard against the sort of build problems suggested by
> > kvv.
>
>
>         MacPorts already sets its internal path for a few things, so this
> suggestion may be easy to implement but might, just might, have
> repercussions that we may want to test more thoroughly (not on the
> verge of a release, in my opinion ;-)
>
> >
> >
> >       (3) Modify existing path modification code to also add MacPorts
> > paths to MANPATH. (This might break other man pages on Tiger where
> > the system provides no meaningful default for MANPATH—maybe we do it
> > only if MANPATH is already defined?)
>
>
>         I could definitely look into this extension to the existing
> postflight script and its implications on both Leopard and Tiger, I
> like its "lowest risk" approach. In this case I'll remove the /etc/
> paths.d and /etc/manpaths.d munging code from the release_1_6 branch
> to safeguard the release, but will not touch it in trunk so that we
> can continue brainstorming over it there.
>
>         Any other suggestions?
>
>         Regards,...
>
>
> -jmpp
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev
>



-- 
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."


-- 
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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20071202/34656293/attachment.html