Perl portgroup, +perl5_30 depends on perl5.28, etc

[Ryan Schmidt]

On May 22, 2020, at 09:52, Craig Treleaven wrote:

> I’m working on a new port and was using the fsdb port as a model.  Oddly, when a non-default variant is selected, it seems the perl portgroup still adds a dependency on the default perl version.  In the case of fsdb, the default variant is +perl5_28:
> 
> $ port info --variants --depends_lib fsdb +perl5_30
> variants: perl5_26, perl5_28, perl5_30
> depends_lib: perl5.30, perl5.28, gzip, p5.30-html-parser, p5.30-io-compress, p5.30-io-compress-lzma, p5.30-test-pod, p5.30-test-pod-coverage, p5.30-test-simple, p5.30-text-csv_xs, p5.30-xml-simple, p5.30-yaml-libyaml
> 
> Note that the first two library dependencies are "perl5.30, perl5.28,”.  Not a huge problem for most users but it could lead to a redundant port installation and/or confusion.
> 
> I can’t follow the code in the port group well enough to say why this is happening.  It isn’t deliberate, is it?

The perl5 portgroup is intended to be used in one of three ways:

1. to make a perl module whose name is "p5-something". The portgroup will create subports like p5.28-something and p5.30-something each of which will depend on the correct perl5.xx.

2. to make a port whose name is "something" that happens to be distributed as a perl module but which is not used as a perl module as a dependency by any other port, for example a port for program that the user might wish to run when the program happened to have been written in perl. If the user might care which perl version is used then the port can offer variants which the portgroup will create.

3. to add perl variants to any port. The portgroup will create variants which will depend on the correct perl5.xx.


fsdb seems to be in category 2 and I can see only 7 total ports in this category. I agree, in this use case the portgroup erroneously adds another perl dependency. Some of the ports in this category "avoid" the problem by overwriting the dependencies that the portgroup had set, which is probably not a solution we should advocate. This should probably be fixed in the portgroup (or just file a ticket for now).