upgrades fail after leopard update

[Ryan Schmidt]

On Jun 13, 2008, at 02:35, Alan Batie wrote:

> Ryan Schmidt wrote:
>
>>>>   if there's a change from what's installed, replace what's  
>>>> installed
>>>> with the new version
>>
>> MacPorts has no way to know "if there's a change from what's   
>> installed"
>
> Given that you can say "port installed" to list what's installed,  
> there must be some sort of registration that could be compared with  
> what would be recorded if the port were built "now".

And I'm saying that the "unique" identifier for what would be built  
"now" (currently made up of the combination of the port name, version  
and variants) might not be any different from the unique identifier  
for what was built "then", even if the resulting software might be  
different. MacPorts just has no way to know. That's why it's an  
excellent suggestion to add the OS version, Xcode version and  
processor architecture to the unique identifier to try to make it  
truly unique.

>> merely upgrading
>> the Xcode version is no reason (usually) to force a port to be   
>> rebuilt (though if we store the Xcode version, we could then make   
>> exceptions for known-bad Xcode versions).
>
> The ease of being able to just say "port upgrade installed" and  
> going home for the night (or to bed or work on a home machine)  
> would make it worth the time of doing unnecessary rebuilds.

You never want "port upgrade installed"; you want "port upgrade  
outdated", if anything. "port upgrade" does not upgrade ports that  
are not outdated, so saying "port upgrade installed" just wastes time  
evaluating ports that won't get upgraded.

Just having a newer version of Xcode should not trigger a port to  
show up in "port outdated", though once we start storing information  
about Xcode version and such with each installed port, there could be  
an optional more-pedantic "outdated" which could list this.

> Keep good logs of course, in case of problems.

MacPorts keeps no logs of any kind at this time. There is a logging  
proposal written, but the feature is not yet coded:

http://trac.macports.org/wiki/LoggingProposal

> If you really want to get fancy, support checkpointing and  
> reversion in case of errors, but let's not go there now ;-)

Not sure what you mean. If you mean the ability to go back to a  
previous version of a port, you already have that ability. When you  
"port upgrade foo", the old version of foo remains installed (but  
deactivated). If you want to go back to the old version, you can  
deactivate the new version and (re)activate the old one.

> The quick fix for right now would be to just add "reinstall" where  
> it just rebuilds what it's already got.

You already have that, for individual ports. To rebuild port foo even  
if port doesn't think it needs to be rebuilt:

sudo port -ncuf upgrade foo

In MacPorts 1.6.0, I don't know a good way to tell it to rebuild more  
than one port at a time. Omitting the -n flag will cause port to  
rebuild some ports many many times. I think this has been fixed in  
trunk but I haven't had occasion to try it.

> As it is now, my ports registry is basically messed up (though not  
> enough to really break it) because to get my mail archive going  
> again, I just did "port install dovecot" and it installed the  
> latest version over the top of the old one, and now as far as the  
> ports system is concerned I have a couple different versions  
> installed.  I suppose it's a "bug" that it did that, but it was a  
> feature in this instance.

Not a bug. Works as intended.

> Hmm.  I seem to have managed 3 somehow:
>
> [1] $ port installed | grep dove
>   dovecot @1.0.0_0+darwin_8
>   dovecot @1.0.13_0+darwin_8+darwin_9 (active)
>   dovecot @1.0.13_0+darwin_9

As I see it, dovecot @1.0.0_0+darwin_8 was installed on Tiger. When  
1.0.13_0 was released, you did "sudo port upgrade dovecot" which  
installed and activated dovecot @1.0.13_0+darwin_8 and deactivated  
(but left installed) dovecot @1.0.0_0+darwin_8. Then you upgraded to  
Leopard. Then you forced the reinstall of dovecot, which now caused  
the +darwin_9 variant to get added, so you ended up with dovecot  
@1.0.13_0+darwin_8+darwin_9 (the error I was telling you about in the  
last mail). Then you asked for dovecot to be installed, and because  
the set of variants MacPorts decided to use (only +darwin_9) differed  
from what was already installed, it built it again, and installed  
(but couldn't activate because of the other version already active)  
dovecot @1.0.13_0+darwin_9. You should now deactivate (and, if you  
like, uninstall) dovecot @1.0.13_0+darwin_8+darwin_9 and activate  
dovecot @1.0.13_0+darwin_9 to get a version that is expected to work  
on Leopard. I can give you no expectations about dovecot @1.0.13_0 
+darwin_8+darwin_9.


> Anyhow, the point is that all the fancy stuff is all well and nice,  
> but just a basic rebuild would be a 90% solution.

If you mean something that would rebuild all ports in order, then we  
don't have it, and I don't think it would be "basic"; I think it  
would be a non-trivial script to write. For me at least.


> Actually, the problem seems even smaller --- it looks like "port  
> upgrade one-port" is working, it's the "installed" arg that for  
> some reason isn't creating an expected file that's blocking the way...
>
> Though I was able to upgrade gettext, but popt is still  
> complaining, so I suppose when I get a chance, I'll have to debug  
> it and file a real bug report:
>
> checking for GNU xgettext... configure: error:
>   *** GNU gettext is required. The latest version
>   *** is always available from ftp://ftp.gnu.org/gnu/gettext/.
>
> Error: Unable to upgrade port: 1

I haven't had a chance to test this and my battery is about to die so  
I'm going to send this mail now. :)