Error after trying to upgrade installed

[Ryan Schmidt]

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.