[MacPorts] #72538: post-activate and pre-deactivate phases aren't executed reliably

[MacPorts]

#72538: post-activate and pre-deactivate phases aren't executed reliably
--------------------+--------------------
 Reporter:  RJVB    |      Owner:  (none)
     Type:  defect  |     Status:  new
 Priority:  Normal  |  Milestone:
Component:  base    |    Version:
 Keywords:          |       Port:
--------------------+--------------------
 I have touched on this before but don't think I ever created a ticket.

 Consider a port that extends/modifies/updates the features provided by
 another port or possibly "base" itself (e.g. a port for shipping an
 updated pextlib that uses a newer `curl` than the one provided by the host
 - as discussed in another ticket).

 Such a port would have to change a configuration file belonging to the
 other port (or a `pkgIndex.tcl` file in the pextlib example), and would
 typically do that in the `post-activate` phase. Ideally it would also have
 a `pre-deactivate` block that restores the standard configuration.

 This does work, but for some reason only in the (de)activation phases
 associated with an install (including `upgrade --force` to reinstall the
 current version).

 For me it has never worked when doing `port deactivate` or `port
 activate`. Most of the time that isn't a big problem but in the scenario
 described above it is because deactivation can leave the "dependent" port
 crippled.

-- 
Ticket URL: <https://trac.macports.org/ticket/72538>
MacPorts <https://www.macports.org/>
Ports system for macOS