K 10
svn:author
V 5
dougb
K 8
svn:date
V 27
2010-04-29T05:55:38.392818Z
K 7
svn:log
V 1952
For -o mode:
   Going back a long ways upg_port was (ab)used to indicate the currently
   installed version of the old port for -o. Originally this was safe since
   it's very rare to have the new port installed already, and it saved a
   little bit of code complexity. However, as more and more features were
   added that utilized the value of upg_port it became increasingly
   unsafe. Particularly, at this time there are 2 related bugs manifest.
   First the wrong information appears in the confirm list (upgrade of
   the old port vs. install of the new) and parsing the old port
   directory. The latter was (mostly) harmless, although in the case of
   an old port directory being DEPRECATED resulted in a fatal error
   when trying to upgrade.

So, make the following changes:
1. Make upg_port an installed version of the new port, if it exists.
2. Introduce ro_upg_port for the existing version of the old port.
3. Factor out some code that was related to how to handle lack of an
   installed version of the old port (since we're already checking that).
4. In the stage after the build of the new port and before the pkg_delete
   of the old port test for upg_port OR ro_upg_port and run the various
   features (library backup for -w, pkg_delete, etc.) as needed for both.
5. In install_failed() notify the user about the backup port for the old
   version.
6. I discoverd in regression testing that the code to invoke -o for MOVED
   ports that we get to as dependencies was still working, but the code to
   automatically invoke -o for a parent port was broken. The problem is
   that we can't just exec a new version if we're the parent, we have to
   cleanly shut down background fetches and other processes, delete temp
   files, etc. So split the parts of safe_exit() that relate to these
   elements into their own function, parent_exit(), and call it both
   from safe_exit() and before exec'ing a new version for -o in this case.

END