Oops. Hit reply instead of reply all... ---------- Forwarded message ---------- From: Randall Wood <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
On 12/2/07, Juan Manuel Palacios <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.macosforge.org/mailman/listinfo/macports-dev > -- Randall Wood [EMAIL PROTECTED] "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." -- Randall Wood [EMAIL PROTECTED] "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
