On Jan 19, 2009, at 07:37, robert delius royar wrote:
So much traffic on this thread, so much time spent answering
questions. But I do not recall any of the answerers trying
port provides /opt/local/lib/libintl.dylib
Sorry; I thought it was already understood that libintl is the
internationalization library and that it is provided by gettext.
That would have pointerd out that the initial problem of gettext
wanting to reinstall itself (perhaps for no good reason) had
removed the dylibs that gettext provides and uses, itself.
"For no good reason" depends on your situation. In this particular
case, gettext was updated from 0.17_3 to 0.17_4 because some 64-bit
issues were corrected. If anyone had installed 0.17_3 with the
+universal variant and had requested 64-bit architectures in the
universal_archs variable in macports.conf, they would have had an
incorrectly-functioning gettext, so for those users, it was necessary
to force a rebuild by increasing the port's revision. If you did not
have gettext installed with the +universal variant, or had not
selected any 64-bit architectures in macports.conf (the default is
only the 32-bit architectures ppc and i386) then you would not have
been affected and would not need to rebuild gettext.
When using MacPorts, you can either assume that MacPorts maintainers
know what they are doing and if they are requesting you to rebuild a
port (as evidenced by it showing up in "port outdated") then you
rebuild it. Or if you have the inclination you can dig deeper,
subscribe to the macports-changes mailing list, monitor the changes
taking place to the ports you use, and evaluate for yourself whether
you need the changes provided in a new port revision, and if you
don't, then don't upgrade the port until it's updated again later
with a fix that you do want.
For many users the former strategy is sufficient, even to the point
of just running "sudo port sync" and "sudo port upgrade outdated" and
letting MacPorts take care of everything.
I believe this highlights some error in the 1.70 base. I say this
because it seems to be faulty UI that allows a user to specify a
variant that when in place the port command can be broken in a
simple upgrade.
I agree it's a MacPorts base issue. A ticket has now also been filed
for this issue:
http://trac.macports.org/ticket/18149
In it, I comment:
"Actually it surprises me that MacPorts base is shelling out to an ln
command at all; why aren't we using the [file link] Tcl command?"
Does anybody know the answer? I haven't yet looked through the
history of base to see if the commit messages give any indication.
I mention above "perhaps for no good reason" because last week when
I upgraded graphviz which upgraded gd2, I got into a loop of trying
to upgrade freetype, zlib and gettext, none of which were outdated
according to port. I finally had to force the reinstallation of
zlib and gettext, force uninstall gd2, freetype, zlib, and gettext
and start over.
Without seeing exactly what commands you typed and what output you
got, I can only speculate that perhaps you used the -f flag to port
upgrade and did not also use the -n flag. This can result in
dependencies being rebuilt even if they are not outdated -- possibly
even multiple times. Nobody wants this, so one should never use the -
f flag with port upgrade without also using the -n flag. However,
MacPorts should never get in any kind of "loop". It might seem that
way, but if you let it run all the way through (which might take
prohibitively long) it would eventually end, so it's not a loop.
That was not the first time I had seen this loop of upgrading a
port that was the same version as the curreny installed version,
followed by failing to install the "new" version because a version
was already in place (the same version). In some cases the process
stopps there; in others it moves to the next port that it either
"thinks" should be upgraded or really should be. Then if that port
depends on one of the ports it has mistakenly identified as
outdated, it goes into the same pattern. On a few occassions I
have found libraries from those ports which wer not in need of
replacement--but replaced anyway--missing. TimeMachine is useful,
then,
If you could provide actual commands typed and verbatim output
received the next time you encounter this problem, that might be
helpful to getting it resolved.
I have the last model of the G5 iMac running 10.5.6, and the
portinstalltype is direct, and portarchivemode is no. 1.7 seems as
though it has sections that are not sure what "direct" mode is by
the way; some ports I have upgraded recently report "activating."
I have not used image mode on this machine at all.
Direct mode is certainly less well tested than image mode. I've never
used it. Is there a particular reason why you are using it?
There are ports that define post-activation phases. Perhaps those are
getting executed even in direct mode, and that is why you see
MacPorts stating it is activating a port, even though in direct mode
there isn't an activation phase...
If you could say exactly what ports do this, we could investigate
further.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
