[MacPorts] #72538: post-activate and pre-deactivate phases aren't executed reliably
MacPorts
noreply at macports.org
Sun May 25 14:47:36 UTC 2025
#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
More information about the macports-tickets
mailing list