Hi Ryan,
On Dec 2, 2007, at 2:39 PM, Juan Manuel Palacios wrote:
On Dec 2, 2007, at 5:49 PM, Ryan Schmidt wrote:
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.
Yes, I agree 100% percent. But please do note that all the changes
I merged into the release_1_6 branch since rc2, except for 2, have
had nothing to do with MacPorts functionality. Mostly just with the
PortIndex2MySQL script (after working with Bill to deploy it on Mac
OS Forge), which, on the one hand, I've been testing locally
extensively for a really long time and, on the other hand, is
something most regular users never even see.
Of the two commits that do have to do with MacPorts functionality:
*) one is a corner-case bugfix against the "dp2mp-move" upgrade code
(paths with spaces embedded in them), which I satisfactorily tested,
and
*) the other is the path munging work by James Berry, which I'm
inclined to remove from the branch.
Note please that my addition was a 100% non-code change, to try to fix
MANPATH which is 100% broken in Leopard, Ryan, a situation that was
not present in Tiger or before. Which isn't to say (as I wrote
earlier) that I'm completely happy with the state of things so far,
but that we do need to fix this problem before a 1.6 release.
James
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
