Oops. Hit reply instead of reply all... ---------- Forwarded message ---------- From: Randall Wood <randall.h.wood@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@macports.org> On 12/2/07, Juan Manuel Palacios <jmpp@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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev

-- Randall Wood randall.h.wood@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@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."