On Dec 2, 2007, at 12:35, Juan Manuel Palacios wrote:
(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 ;-)
Yes, just to chime in a bit on that point: I'm rather unhappy about
all these changes that appear to be going into 1.6.0 after we've
already had two release candidates. That's not what release candidate
means. Release candidate means that it is a candidate for release,
and if no major problems are found, it will be released as is. It
does not mean that we will add lots of other code and then release
it, especially not with another release candidate. I don't want
another MacPorts 1.4.0--no wait, 1.4.1--no wait, 1.4.2--no wait,
1.4.3. That's exactly what release candidates are supposed to prevent.
Ok, if the manpages aren't working on Leopard because of this, then
we could fix it. On the other hand, it's equally broken in all
previous versions of MacPorts, so we're not introducing any
additional breakage, which is what I'm most interested in. New
releases of MacPorts should only improve things. Even a little
improvement at a time is fine. Introducing major changes to how key
parts work, right before a new release of MacPorts, is not to my liking.
So my suggestion would be to either leave the path setup the way it
is in 1.5.2, let it continue to be broken in Leopard, and think about
how best to fix it after release, or to take the (I hope) simpler
route of munging MANPATH in addition to PATH, only if MANPATH is set.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
