Port Function to Handle OS Upgrades

[Ryan Schmidt]

On Oct 23, 2009, at 14:44, Jeremy Lavergne wrote:

> What are our thoughts on providing a new function to handle  
> preparing for an OS upgrade (or run immediately following)?
>
> This procedure would need to:
> * remove all build directories
> * trash all irrelevant archives
> * dump a list of what is installed (either to be read in by another  
> function or simply catted to port)
> * uninstall everything
>
> We can provide two separate functions, really.  One, to dump the  
> installed and their variants; another to remove all irrelevant files  
> in the tree.
>
> There are many more instances where we can get irrelevant files in  
> the tree, such as upgrades.  Perhaps having this function be  
> abstract enough we can use it in both instances would be to our  
> coding advantage.

I'm not sure how you define "irrelevant".

When we've talked about this problem before, the strategy I wanted to  
take was:

* sudo port install (and upgrade) should record in the registry more  
info than they currently do: store also the OS version, Xcode version,  
MacPorts version, build_arch, universal_archs, and any other relevant  
settings from macports.conf that would influence how the software is  
built.

* sudo port outdated (and upgrade) should take into consideration more  
than just the epoch, version and revision that they do now: they  
should definitely consider the OS version, build_arch, and  
universal_archs (and possibly other variables), and present ports to  
the user for rebuilding if, e.g., the major OS version changes, or the  
build_arch changes and the port is not universal, or the  
universal_archs change and the port is universal.

I believe there are already three tickets encompassing parts of the  
above.

We haven't talked about build directories before, but old build  
directories can cause problems, especially if they were from an older  
OS. MacPorts has some criteria for when to auto-clean a port --  
currently I think it's just if the portfile is newer than the build  
directory. We should add to that if the OS version, Xcode version,  
MacPorts version, build_arch, or universal_archs have changed since  
the build started. This means we would have to record the these  
variables in the build directory somewhere. Maybe not in the state  
file; maybe we need a new file to store this.

I don't think we have a ticket for this part yet.