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.
(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
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
