requested (meta) ports get uninstalled on uninstall leaves

[nick@…]

I installed p5-Template-Toolkit, but afterwards doing uninstall leaves uninstalled it (or actualy p5.22-template-toolkit) again.

It seems that if the meta port is not actually installed, het requested flag should be transferred to the port it installed instead.

nick@Himkje:~ % sudo port install p5-template-toolkit
--->  Computing dependencies for p5-template-toolkit
--->  Dependencies to be installed: p5.22-template-toolkit
--->  Fetching archive for p5.22-template-toolkit
--->  Attempting to fetch p5.22-template-toolkit-2.260.0_0.darwin_15.x86_64.tbz2 from https://packages.macports.org/p5.22-template-toolkit
--->  Attempting to fetch p5.22-template-toolkit-2.260.0_0.darwin_15.x86_64.tbz2.rmd160 from https://packages.macports.org/p5.22-template-toolkit
--->  Installing p5.22-template-toolkit @2.260.0_0
--->  Activating p5.22-template-toolkit @2.260.0_0
--->  Cleaning p5.22-template-toolkit
--->  Cleaning p5-template-toolkit
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.
nick@Himkje:~ % sudo port setrequested p5-template-toolkit
nick@Himkje:~ % sudo port uninstall leaves
--->  Deactivating p5.22-template-toolkit @2.260.0_0
--->  Cleaning p5.22-template-toolkit
--->  Uninstalling p5.22-template-toolkit @2.260.0_0
--->  Cleaning p5.22-template-toolkit

[nick@…]

nick@Himkje:~ % sudo port install p5-template-toolkit
--->  Computing dependencies for p5-template-toolkit
--->  Dependencies to be installed: p5.22-template-toolkit
--->  Fetching archive for p5.22-template-toolkit
--->  Attempting to fetch p5.22-template-toolkit-2.260.0_0.darwin_15.x86_64.tbz2 from https://packages.macports.org/p5.22-template-toolkit
--->  Attempting to fetch p5.22-template-toolkit-2.260.0_0.darwin_15.x86_64.tbz2.rmd160 from https://packages.macports.org/p5.22-template-toolkit
--->  Installing p5.22-template-toolkit @2.260.0_0
--->  Activating p5.22-template-toolkit @2.260.0_0
--->  Cleaning p5.22-template-toolkit
--->  Cleaning p5-template-toolkit
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.
nick@Himkje:~ % sudo port setrequested p5-template-toolkit
nick@Himkje:~ % sudo port uninstall leaves
--->  Deactivating p5.22-template-toolkit @2.260.0_0
--->  Cleaning p5.22-template-toolkit
--->  Uninstalling p5.22-template-toolkit @2.260.0_0
--->  Cleaning p5.22-template-toolkit

[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't be asked to rememeber which Perl version is installed where.

[ryandesign (Ryan Carsten Schmidt)]

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.

[nick@…]

But the meta port is not installed itself. THAT is something the ports subsystem is aware of.

[ryandesign (Ryan Carsten Schmidt)]

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.

[nick@…]

Ok, thanks for your -very- elaborate explanation. Indeed p5.16-template-toolkit was installed. I guess I am getting confused by the fact that multiple Perl versions can be installed simultaneously.

I tried to fix all other ports the same way, but ended up uninstalling all Perl ports and reinstalling the ones that I could remember (I'll find out incrementally what I need eventually, so it's not that big a deal).

Thanks again! This text should be contributed to a FAQ.

[mojca (Mojca Miklavec)]

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: the buildbot builds a binary with new variants, so those who install the port from scratch do get the right thing, while "port upgrade outdated" on installed ports won't fix variants even if the port gets revbumped. See also #46956.

[ryandesign (Ryan Carsten Schmidt)]

Replying to nick@…:

Ok, thanks for your -very- elaborate explanation. Indeed p5.16-template-toolkit was installed. I guess I am getting confused by the fact that multiple Perl versions can be installed simultaneously.

This was intended to be a convenience to users who needed a specific version of perl. We do the same for other language ports. However, in the case of perl5 we're having some debate as to whether we want to continue offering multiple versions. There are pros and cons.

I tried to fix all other ports the same way, but ended up uninstalling all Perl ports and reinstalling the ones that I could remember (I'll find out incrementally what I need eventually, so it's not that big a deal).

That'll work.

Thanks again! This text should be contributed to a FAQ.

It wasn't documented before because I didn't realize the problem existed until I reread your ticket description and wrote my response. When designing the current perl5 portgroup we probably didn't anticipate that variants of the perl5 port would ever be removed; it was the removal of the old variants that caused the problem you experienced. I would rather fix the problem than document it, but it may be hard to fix.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca:

• 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: the buildbot builds a binary with new variants, so those who install the port from scratch do get the right thing, while "port upgrade outdated" on installed ports won't fix variants even if the port gets revbumped. See also #46956.

This isn't specific to perl module ports, but:

• If you add a variant to a default_variants line, you should increase the revision so that any users who already had the port installed without that variant will get it reinstalled with that variant.
• If you remove a variant from a default_variants line, you should not increase the revision because MacPorts preserves variant selections across upgrades; forcing a user to rebuild the port will not affect the variants with which they have it installed as long as those variants still exist.
• If you remove a variant from a port entirely, you should increase the revision so that any users who had the port installed with that variant will get it reinstalled without the variant.
• If you add a new non-default variant to a port, you probably don't need to increase the revision. The only users for whom increasing the revision would be relevant is those users who have that variant name listed in their variants.conf file.