[MacPorts] #49645: `port -n upgrade --force foo` should deactivate after creating the new archive

[MacPorts]

#49645: `port -n upgrade --force foo` should deactivate after creating the new
archive
-------------------------+--------------------------------
 Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
     Type:  defect       |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  base         |    Version:  2.3.4
 Keywords:               |       Port:
-------------------------+--------------------------------
 I think this has only been touched up on the ML:

 Currently, reinstalling a port with `port -n upgrade --force foo` will

 u0) do an archivefetch or verify if the `port destroot` phase has been
 terminated
 u1) deactivate the currently active version of foo
 u2) create the archive in ${prefix}/var/macports/software/foo
 u3) activate that archive (unpack it, move files into place)

 Installing a new version of the same port has the following operation
 sequence:
 i0) do an archivefetch or verify if the `port destroot` phase has been
 terminated
 i1) create the archive in ${prefix}/var/macports/software/foo
 i2) deactivate the currently active version of foo
 i3) activate that archive (unpack it, move files into place)

 The sequence i1,i2 is appropriate, the sequence u1,u2 much less. The
 difference becomes noticeable when `foo` is a large port like Qt: the
 lapse of time that no version is active is significantly longer than
 required and desirable. Indeed, running dependents can run into issues;
 this is clearly then case with KDE PIM applications like kmail (and its
 myriad of helper agents) which tend to abort or crash when Qt disappears
 for long enough.

 NB: doing `port upgrade foo` of a port that has a new version pending has
 the same sequence order, i1,i2!

 I have had a look at macports::_upgrade but that procedure is too complex
 to assess easily whether the u1 and u2 can be interchanged in the upgrade
 sequence. However, I don't see the difference between reinstalling the
 same version of a port (via upgrade --force) or upgrading to a new
 version, so I assume that that same order of operations can be followed
 during a reinstall. Hence filing a '''defect''' ticket instead of an
 '''enhancement''' request.

-- 
Ticket URL: <https://trac.macports.org/ticket/49645>
MacPorts <https://www.macports.org/>
Ports system for OS X