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).

Reply via email to