#51498: requested (meta) ports get uninstalled on uninstall leaves ---------------------+-------------------------------- Reporter: nick@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.4 Resolution: | Keywords: Port: | ---------------------+-------------------------------- Comment (by nick@…): Just so know I know: I -could- install p5.22-t-t instead, but what then is the point of meta ports? I work on many systems and can be asked to rememeber which Perl version is installed where. -- Ticket URL: <https://trac.macports.org/ticket/51498#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X

#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@…): * type: defect => enhancement Comment: MacPorts base (and its concept of something be requested) does not have any knowledge of the specifics of the perl module ports. MacPorts base doesn't have any concept of meta ports; it's something implemented entirely in the portfiles. MacPorts base does not see a meta port's dependency on one of its subports as any different from any other port's dependency on another port. So I'm not sure how we would implement such an enhancement. -- Ticket URL: <https://trac.macports.org/ticket/51498#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X

#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

#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 mojca@…): * cc: devans@… (added) Comment: I'm adding David to CC (even if he is absent at the moment; he'll have a chance to follow the ticket when he's back). Ryan, thanks a lot for the very precise analysis which made me aware of additional problems I didn't know about earlier. I wonder if `p5-whatever` should perhaps print a note like "you probably want to install `p5.xx-whatever`" and would not install anything at all (python modules don't install anything for example, but I admit that I'm often confused as I'm used to run "`sudo port -v test`" without specifying port name; this doesn't work with python modules, but I don't get any warning either). I'm sure that some users would complain though (I need to check, but I believe that some developers insist in not specifying the perl version in `port:p5-whatever` for dependencies, arguing that their ports work with any given Perl version anyway). I would argue that the ports could be revbumped at some point, but revbumping wouldn't make any difference at all if users change their default perl version earlier or later. * What happens if users install `p5.22-whatever` (and `p5.22-whatever` is "selected") and then `p5.22-whatever` gets `replaced_by` `p5.24-whatever`. Will `p5.24-whatever` still be selected? * I'm generally slightly worried about the fact that the registry doesn't change if (default) variants change. I probably never revbump ports after changing default variants. I thought that worked properly out-of-the-box. -- Ticket URL: <https://trac.macports.org/ticket/51498#comment:8> MacPorts <https://www.macports.org/> Ports system for OS X