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