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 > [email protected] > https://lists.macosforge.org/mailman/listinfo/macports-dev _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
