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