upgrades fail after leopard update

[Alan Batie]

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 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)
find out what version of os is installed

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

Obviously, retain any existing configs and data (e.g. I'd be *very* 
upset if upgrading dovecot removed my mail archive...).  If there's a 
major change in the application that requires config file changes, that 
should be flagged before the upgrade starts and allow the choice of 
skipping that one port or aborting the entire process.  Automatically 
shooting the application developers who made such a requirement is 
optional ;-)

Having the port prompt you for required change info and updating the 
config accordingly so that it will at least run as it did before, while 
warning you that there are major changes that you should look into would 
be gravy.

Library versions that are incompatible should always be able to 
co-exist.  It was really frustrating in the early-to-mid days of tcl to 
find two apps (actually, it seemed like *every* app) requiring different 
versions of tcl that installed themselves in the same place.

But I digress...

> one does it once per major OS release, which is no more frequently than
 > once a year.

Hopefully!

> Also, testing such a script could be difficult.

That's why I really want to run osx in a vm, but haven't gotten around 
to trying any of the hacks yet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3263 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.macosforge.org/pipermail/macports-users/attachments/20080612/d415a523/attachment.bin