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