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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Craig Treleaven
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?

Craig

Reply | Threaded
Open this post in threaded view
|

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

ryandesign2
Administrator


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 | Threaded
Open this post in threaded view
|

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

Craig Treleaven
> On May 23, 2020, at 12:39 AM, Ryan Schmidt <[hidden email]> wrote:
>
> 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).
>
Thank you again, Ryan, for a concise but detailed explanation.  I take it this summary of the 3 uses of the perl5 portgroup isn’t documented anywhere?

Re category 2, I guess there are now 8 ports using the portgroup this way since I committed xmltv yesterday.  xmltv is a suite of nearly 50 programs for downloading and manipulating television listings data.  These programs just happen to be perl scripts.  As I was working on the port, it was initially producing subports like p5-28-xmltv and p5.30-xmltv PLUS variants to each port (+perl5_28 or +perl5_30).  Sort of a hybrid of categories 1 and 2.  The “fix” was to move the github.setup line _before_ the perl5.setup line in the port file.  I think this worked because the github.setup line defines the Name variable.  This behaviour seems pretty obscure to me but maybe it would be obvious if I could read the portgroup code better.

I can take a stab at writing a section for the guide if someone more conversant will review and edit.  Or is there work in progress somewhere?

Craig

Reply | Threaded
Open this post in threaded view
|

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

ryandesign2
Administrator


On May 23, 2020, at 08:14, Craig Treleaven wrote:

> On May 23, 2020, at 12:39 AM, Ryan Schmidt wrote:
>
>> 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).
>>
> Thank you again, Ryan, for a concise but detailed explanation.  I take it this summary of the 3 uses of the perl5 portgroup isn’t documented anywhere?

I think you're right that it hasn't been documented. It's certainly not here:

https://guide.macports.org/#reference.portgroup.perl


> Re category 2, I guess there are now 8 ports using the portgroup this way since I committed xmltv yesterday.  xmltv is a suite of nearly 50 programs for downloading and manipulating television listings data.  These programs just happen to be perl scripts.  As I was working on the port, it was initially producing subports like p5-28-xmltv and p5.30-xmltv PLUS variants to each port (+perl5_28 or +perl5_30).  Sort of a hybrid of categories 1 and 2.  The “fix” was to move the github.setup line _before_ the perl5.setup line in the port file.  I think this worked because the github.setup line defines the Name variable.  This behaviour seems pretty obscure to me but maybe it would be obvious if I could read the portgroup code better.

Knowing what github.setup and perl5.setup do, I can see how the behavior would be different depending on the order in which you call them, and that that would be confusing.

I was going to tell you that I couldn't think of any other ports that use both the github and the perl5 portgroups together and that they might not coexist well, but then I checked and I found several ports that apparently use both successfully, for example ghsum, cpan2port, po4a. They don't call perl5.setup at all. Is it possible that you don't need to call perl5.setup in xmltv either, and that that would fix the erroneous dependency problem?


> I can take a stab at writing a section for the guide if someone more conversant will review and edit.  Or is there work in progress somewhere?

Not that I'm aware of.