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.
