`port -n upgrade --force foo` should deactivate after creating the new archive

[RJVB (René Bertin)]

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.

[jmroot (Joshua Root)]

Can't be done under the current model. You can't have the exact same version of the same port installed twice. Note that your description of step u1 is incorrect, what actually happens is that foo is uninstalled. That has to happen so it can be installed again. Installing is what creates the archive.

[RJVB (René Bertin)]

Hmmm, so how do you explain that components of a port remain available until after the archiving step when I do port -nd upgrade --force (= with the debug flag)?

Anyway, this explains why the archive creation doesn't show up as a separate step in the state file, and that's actually what should happen. Make the archive, and then install from there. That at least seems to be possible, because activation consists of unpacking the archive into a temp. directory, and then moving the contents of that directory into ${prefix}. Dissociation archiving and installing would also make it possible to "install" a port version without activating it, i.e. upgrade a port while an older version is active.

Would that split be hard to implement (= should I have filed this ticket in time for GSoC :))?

BTW, how is the install of a binary package implemented? IIRC they're downloaded in var/macports/incoming/verified, and then what? Are they unpacked and re-archived into var/macports/software by the installation procedure? Or is it the downloaded tarball that is moved into var/macports/software at the end of the installation procedure?

In the latter case, it seems that a port reinstall command could package ${destroot} into a tarball under var/macports/incoming/verified, which could then be treated as the result of an archivefetch. (Hooks for that seem to be in place, because there's always an archivefetch entry after the destroot entry in the state file of a port installed from source.) You'd still need the uninstall (I can see that), but you'd gain the time of creating the archive, which is the most expensive step.