#51498: requested (meta) ports get uninstalled on uninstall leaves --------------------------+-------------------------------- Reporter: nick@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.4 Resolution: | Keywords: Port: | --------------------------+-------------------------------- Changes (by ryandesign@…): * cc: ryandesign@…, mojca@… (added) Comment: It looks like at the time that you typed `sudo port install p5-template- toolkit`, p5-template-toolkit had already been installed, so MacPorts did not have to reinstall it. However, your transcript shows that its dependency p5.22-template-toolkit was then installed. This implies that perhaps you had a different variant of the perl5 port installed when you originally installed p5-template-toolkit. The p5-* ports are a bit strange in that which of their subports they declare a dependency on varies based on which variant of the perl5 port you have installed. I don't consider this to be good behavior, and none of our other ports behave this way, but that's how it is right now. Consider this series of steps: 1. You installed perl5 with the +perl5_16 variant, perhaps because you just typed `sudo port install perl5` and +perl5_16 was the default variant of the perl5 port at that time (before January 6, 2016). 2. You typed `sudo port install p5-template-toolkit`. Because perl5 was installed with the +perl5_16 variant, this caused a dependency on p5.16 -template-toolkit to be declared which caused the p5.16-template-toolkit port to be installed. MacPorts recorded in the registry that p5-template- toolkit was installed and that it had a dependency on p5.16-template- toolkit, thus p5.16-template-toolkit is not considered a leaf, and cannot be uninstalled without first uninstalling p5-template-toolkit. 3. You installed perl5 with the +perl5_22 variant, perhaps because +perl5_22 was made the default variant in r143798 and earlier perl5_XX variants were removed from the perl5 port in r144338 (on January 6, 2016) and you upgraded to that version. 4. You typed `sudo port install p5-template-toolkit`. Because perl5 was by then installed with the +perl5_22 variant, a dependency on p5.22-template- toolkit was declared. MacPorts ran through the dependencies, found that p5.22-template-toolkit was not installed, and installed it. However, because the version, revision and epoch of p5-template-toolkit had not changed from what they were at step (2), MacPorts did not consider it to be outdated and therefore did not reinstall it. Therefore the registry continues to reflect what it did at step (2), namely that the installed p5 -template-toolkit has a dependency on p5.16-template-toolkit, and p5.22 -template-toolkit is thus considered a leaf since no installed port is recorded in the registry as having a dependency on it. One way to fix your installation would be to forcibly reinstall the stub port: {{{ sudo port -n upgrade --force p5-template-toolkit }}} This will get the correct current dependencies of p5-template-toolkit recorded in your registry (but the registry will again be wrong if you ever change which variant of the perl5 port you have active). I'm not saying this is all good behavior, just trying to explain why it's happening. I think everything is behaving as designed, but all of the implications of the design were not considered at the time. Ticket #50000 discusses ideas about improving the packaging of the perl ports and modules. As for your suggestion to transfer the requested flag from the port you actually requested to one of its dependencies, I don't see how we could do that because the whole point of the requested flag is to indicate which ports you explicitly requested. If you requested p5-template-toolkit, that's the port that will have its requested flag set in your registry. MacPorts base does not know anything about the conceptual relationship between p5-template-toolkit and p5.22-template-toolkit and cannot guess that you actually meant to request p5.22-template-toolkit. You said you "can't be asked to rememeber which Perl version is installed where", but I think that at this point, with the way MacPorts and these ports are programmed today, you really do have to take some responsibility for that, know which version of perl is installed, and take care that the corresponding versions of any needed p5.XX-* module ports are installed. -- Ticket URL: <https://trac.macports.org/ticket/51498#comment:6> MacPorts <https://www.macports.org/> Ports system for OS X