Deactivating "current" Portfile's installed subport

[Joshua Root]

On 2013-9-7 06:33 , Jeremy Lavergne wrote:
> MacPorts skips deactivating a (newly defined e.g. py34-gnupg) subport installed from the "current" Portfile when using psuedo portnames in the deactivation command.
> 
> Specifically, I edited ./Portfile (py-gnupg) to allow Python 3.4 and installed it "sudo port install subport=py34-gnupg". Afterwards, "sudo port deactivate active and not rdepof:py27-googleappengine" bailed on the removal of python3.4 claiming a dependent was still installed. I believe MacPorts' default behavior is to deactivate in the proper order.
> 
> Does MacPorts check for immediate dependents and avoids deactivating but intentionally not do the same checks ahead of time when calculating the whole dependency tree? or is this only because of the "current" Portfile (e.g. not in PortIndex)? or is it that MacPort doesn't calculate the dependencies "properly" in each step?
> 
> Workaround: I was able to remove py34-gnupg by explicitly naming it in a deactivate command.

Evaluation of pseudo-portnames happens before anything related to the
action that is being run. Try echoing "active and not
rdepof:py27-googleappengine" to see what it expands to.

Only registry info is used by portlist_sortdependents, so a port not
being in the index should make no difference. Print out the portlist
here to see what order it comes up with:
<https://trac.macports.org/browser/trunk/base/src/port/port.tcl#L2461>

- Josh