upgrades fail after leopard update

[Cameron Simpson]

On 12Jun2008 17:27, Alan Batie <alan at batie.org> 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.

> 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

As remarked, it would be good to distinguish chosen variants from
auto-variants in the port install state information.

Gentoo's emerge has a --pretend mode that is very useful. Does port
install have that?

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/