[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:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by RJVB):

 > Many ports use pre-/post- activate/deactivate without problems, as far
 as I know.

 I may have spoken without sufficient samples for the pre-deactivate step
 (I forgot I have a port for ZFS that takes care of unloading the kexts
 before deactivation and AFAICR that works reliably enough) but I'm certain
 that the post-activate was always problematic *after* the _first_
 activation of a newly (re)installed port.

 Of course you don't notice that if the post-activation action is one-shot
 only, e.g. creating a non-payload config file from a provided (payload)
 default sample.

 > Ports shouldn't attempt to extend/modify/update other ports or base.

 See #51516

 I have no direct examples of software that would require changing a
 "system" configuration file in order to be acknowledged/loaded by the host
 software, but I don't see why it wouldn't be acceptable to do that (rather
 than have the user do it) as long as the file in question is not actually
 part of a port.

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