Niels Thykier:
> Helmut Grohne:
>> Hi Niko,
>>
>> On Sun, Dec 15, 2019 at 08:34:47PM +0200, Niko Tyni wrote:
>>> I don't understand. AFAICS if the interpreter needing the modules is
>>> /usr/bin/perl, the perl:any dependency will pull in compatible standard
>>> library extension modules: the perl -> perl-base dependency guarantees
>>> perl will be the same arch as /usr/bin/perl, and the perl -> libperl5.30
>>> dependency pulls in the modules for that architecture.
>>>
>>> If it's an embedded interpreter, a compatible set of those is already
>>> shipped with the interpreter (in libperl5.30).
>>>
>>> So where's the problem here?
>>
>> There is no problem. Thank you for the explanation.
>>
>> Does that mean we can move forward with using perl:any for modules?
>>
>
> Hi,
>
> If you are in agreement over this, then I am happy to implement the change.
>
>> I think the check in dh_perl line 142 should be changed from
>>
>> perlarch .= ':any' if $deps == PROGRAM and not $dh{V_FLAG_SET};
>>
>> to
>>
>> perlarch .= ':any' if $deps & (PROGRAM|PM_MODULE) != 0 and not
>> $dh{V_FLAG_SET};
>>
>> Helmut
>>
>
> Wouldn't that be:
>
> perlarch .= ':any' if ($deps & (~(PROGRAM|PM_MODULE))) == $deps \
> and not $dh{V_FLAG_SET};
>
>
No, that was wrong too.
Any way, the following question stands:
> If $deps contains any of XS_MODULE or ARCHDEP_MODULE, then I presume we
> should use "perl" rather than "perl:any" - even if there is a perl
> script/perl module.
>
> Thanks,
> ~Niels
>
When answered, I get to play with bit patterns until I remember the
correct rune.
Thanks,
~Niels
