Re: Bug#774068: ExtUtils-MakeMaker and NO_PERLLOCAL

On 11/06/2022 12:58, Damyan Ivanov wrote:
> -=| Niko Tyni, 30.12.2014 11:47:23 +0200 |=-
>> (cc'ing the debian-perl list)
>>
>> On Tue, Dec 30, 2014 at 08:38:56AM +0000, Damyan Ivanov wrote:
>>> -=| Andrew Beverley, 29.12.2014 00:16:14 +0000 |=-
>>>> Is there any harm in having the option in there, especially as the
>>>> upstream version of EU-MM defaults to creating perllocal.pod files, and
>>>> provides this option to prevent it happening?
>>>
>>> As I see it, adding and maintaining a line to 2000+ debian/rules files
>>> is a bit of a burden. Not an unbearable one, but we embraced the tiny
>>> dh rules exactly because they made things really simple.
>>>
>>>> Presumably Debian's version uses a patched version of EU-MM, which was
>>>> required before this option was available.
>>>
>>> I wonder if debhelper would be the right place to add this. This would
>>> solve the problem this patch solves, and maybe also simplify the patch
>>> in the perl package package [1]
>>>
>>> [1]
>>> https://anonscm.debian.org/cgit/perl/perl.git/tree/debian/patches/debian/no_packlist_perllocal.diff
>>
>> Right, that seems like the right long term approach to me. Ideally,
>> debhelper could pass both NO_PACKLIST and NO_PERLLOCAL to EU::MM, and
>> the above patch wouldn't be needed at all.
>>
>> This would be a similar transition to the (still unfinished) PREFIX one,
>> see #579461 and
>>   https://lintian.debian.org/tags/debian-rules-makemaker-prefix-is-deprecated.html
>>
>> Packages not using the short form dh rules would need to be modified
>> before the patch could be removed. The required steps would be something
>> like
>>   1) change the Perl policy to recommend NO_PACKLIST + NO_PERLLOCAL
>>   2) change debhelper v9 to use them
>>   3) add a lintian check and/or do a mass bug filing for the other packages
>>   4) wait for (most of) the packages to be fixed
>>   5) change the Perl policy to require NO_PACKLIST + NO_PERLLOCAL
>>   6) remove the patch from the perl package
> 
> I've been thinking about this. Even made the changes in debhelper¹ and
> considered a possible wording for the Perl policy.
> 
>   ¹ https://salsa.debian.org/dmn/debhelper/-/commits/b9cdc9696464f67f0c75479383a002ff666ffd6b
> 
> Then it occured to me that this is a titanic work that would take
> months if not years - rebuilding the archive, analyzing the results,
> providing patches to the packages that need them and track their
> progress.
> 
> All this so that a patch is dropped from Debian's EU:MM and packages
> created with dh-make-perl could be built in a rather non-standard
> environment.
> 
> And perhaps the other patches to Debian's EU:MM also have some purpose
> that would still be missing, so another round of the same would be
> needed.
> 
> Somehow, to me it seems that the gain is not worth the effort. By
> a huge margin.
> 
> So how about this instead:
> 
> Add a special option to dh-make-perl like '--pristine-upstream-eumm'
> that causes it to make whatever changes are necessary to the resulting
> package for it to build with the non-standard envronment. Including
> a warning to the docs that such a package is not intented for the
> official Debian archive.
> 
> Andrew, are you still interested in this and willing to provide
> a merge request/patch that provides such an option?

Thanks for coming back to this and for the willingness to solve it.

> If you have solved the issue by other means (e.g. --data-dir), then
> perhaps we should just close this bugreport.

I've actually now always been in the habit of prefixing any use of 
cpan2deb with the following, which I think solves the problem:

PERL_MM_OPT='NO_PACKLIST=1 NO_PERLLOCAL=1'

Reading through the history of this bug though, I'm not sure I really 
need that anymore, as I don't think I'm using a local version of EU::MM 
(presumably the one now shipped with Debian is new enough for most 
purposes).

So yes, I think just closing the bug report is best. At least there is a 
history here for anyone else encountering the same issues.

Many thanks for your assistance.

Andy