upgrades fail after leopard update

[Ryan Schmidt]

On Jun 12, 2008, at 20:24, Cameron Simpson wrote:

> On 12Jun2008 17:27, Alan Batie wrote:
>
>> Ryan Schmidt wrote:
>>
>>> One way to improve this would be to remove autoselected variants  
>>> during
>>> upgrade if they aren't applicable anymore. For example, if you  
>>> have a
>>> port installed with +darwin_8 but you're now on Leopard,  
>>> upgrading the
>>> port should deselect the darwin_8 variant.
>>>
>>> Can you think of other concrete ways we could improve the situation?
>
> I think you might have a "system signature" of some kind. Eg a string
> consisting of os-revision/cpu(ppc/intel)/xcode-version. Let macports
> track that (per installed port I guess so a partial upgrade doesn't  
> get
> fubarred) as part of its "upgrade needed" criteria.

Good! I like it. Just storing all this info with each port when it's  
installed should be the first step. Providing a way to then display  
this info (maybe an enhanced version of "port installed") and making  
use of that info in "port outdated" can be later enhancements.

I had suggested in the "Universal issues" [1] thread that we should  
store the build CPU architecture, the target architecture(s), and the  
major OS version, but we may as well store the complete OS version,  
and storing the Xcode version is a great idea too. We've certainly  
had some issues with earlier Xcode versions (2.0 <= x < 2.4.1) that  
it would be nice to be able to identify. Though often the issue is  
that the port won't compile at all.

[1] http://lists.macosforge.org/pipermail/macports-dev/2008-June/ 
005366.html


>> I would look at the upgrade process as iterating thus:
>>
>> get list of what's installed
>> generate dependency graph
>> scan the graph to break cycles and turn it into a tree?
>>   (not sure if you even have cycles, but I'd be surprised
>>    if they weren't possible, so you probably already have
>>    to deal with that anyhow)
>
> Breaking cycles doesn't turn it into a tree, but fortunately that's  
> ok;
> an acyclic digraph is fine - you can traverse it like a tree and just
> need to avoid rebuilding a package you rebuilt on another path. Which
> macports seems to do just fine anyway.
>
>> find out what version of os is installed
>
> Plus tools, maybe. See signature stuff above.
>
>> traverse the tree depth first, for each port:
>>   what version is current
>>   what version is installed
>>   if there's an os specific variant, does the one installed match the
>> current platform?
>>   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" since it's quite possible that the software will build  
differently on, say, Leopard than it would on Tiger, even if the port  
version, chosen variants and processor architecture don't change. The  
Xcode version will change since on Tiger you'd have at best Xcode 2.5  
and on Leopard you'd have at least Xcode 3.0, but 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).