Order of activation/deactivation pre/post phases

[René J.V. Bertin]

On Wednesday February 25 2015 13:54:26 Artur Szostak wrote:

I had a very similar question recently, but about the deactivation of the current version of a port being upgraded. That's the 1st thing that's done after the new version's destroot, at least when you prepare the destroot "manually" instead of just letting the install/upgrade command go through to the whole process.
With the current implementation, you can end up spending a considerable time with no version activated at all, while the new version is packaged and then unpacked and moved into place.
Try as I might, I cannot see a reason to deactivate the current version only just before the final act of moving the new version in place.

R.
> Hi,
> 
> Why does a pre-activate phase happen before a deactivation phase when upgrading from an older port revision to a newer one?
> 
> I would have expected the following order:
>   ...
>   pre-deactivate v1
>   deactivate v1
>   post-deactivate v1
>   ...
>   pre-activate v2
>   activate v2
>   post-activate v2
> 
> But MacPorts (2.3.3) uses the following order:
>   ...
>   pre-activate v2
>   pre-deactivate v1
>   deactivate v1
>   post-deactivate v1
>   ...
>   activate v2
>   post-activate v2
> 
> Kind regards.
> 
> Artur
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev