Debian Perl 5.24 - Override its default "dotless @INC" behaviour

[mw9]

Debian's Perl 5.24, included in the Stretch release (Debian 9), implements a "dotless @INC", with effect similar to that adopted by Perl 5.26. One immediate effect is that YAML-LibYAML-0.35 fails to build under Debian's Perl 5.24.

This behaviour can be suppressed by setting PERL_USE_UNSAFE_INC=1, as with Perl 5.26.

As this is a cross-platform script, it seems sensible to have Debian's Perl 5.24 behave the same as a 'regular' Perl 5.24, thereby eliminating one potential source of frustration in the future.

This change achieves that as follows:

Identifies a Perl 5.24 which doesn't have "." as the last member of its @INC. If so, sets PERL_USE_UNSAFE_INC=1 for the duration of the buildme.sh script.

Refer: https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#perl "Perl changes that may break third-party software"

Debian's implementation of this feature takes place through a sitecustomize.pl script.

[mw9]

I was unaware of the "dotless@INC" issue until a few days ago. I fell over it when building armel binaries on Debian Stretch. Debian's Perl 5.24 is likely to be with us for quite some time, so, to me, it seems sensible to handle it in the build script.

The change does not offer a "user override", a knowledgeable user can edit the script if he wishes to compare behaviours.

I do not seek to address Perl 5.26, which has a "dotless@INC" across all platforms. That discussion is perhaps better had in the contect of Perl 5.26++.

An alternative is to put instructions in the README.

[mherger]

Interesting: I've built for 5.26 and 5.24 on several platforms, mostly Debian or Ubuntu, and never had a problem. Or I somehow missed it :-).

Whatever: why not set that value right away, for all of those builds?

[mw9]

My impression, which is based on very limited reading and knowledge, is that setting that value for Perl 5.26 may be a very OK thing to do in the context of a build system. Many CPAN packages will do it anyway until they are suitably updated. But the PERL_USE_UNSAFE_INC override will disappear in due course. (Perl 5.30 ?)

But I noted that this commit, https://github.com/Logitech/slimserver-vendor/commit/9e6b520f17cec0adeca36348c5538681c78f01c3, deals with the issue (on 5.26) by upgrading YAML-LibYAML. There may be a very good reason for that, as opposed to using PERL_USE_UNSAFE_INC=1.

Perhap @fsbruva can provide an informed appraisal.

At present it seems that only YAML-LibYAML is directly in point, so it's not a big issue. And perhaps it will be the only issue, given that upstream CPAN packages may have adapted themselves by the time LMS comes to use them.

[mherger]

Yes, seems reasonable to just bump YAML for 5.24, too. As that code is already in place anyway. Could you please modify that part of the script in favour of this change?

[fsbruva]

@mw9 Sorry I didn't see this until now - even though you mentioned me, I received no email. My rationale for not taking the "USE_UNSAFE_INC" route was that there was nothing intrinsic about LMS that required it. If no version of YAML was compatible with 5.26, I might have been forced into it. Additionally, I also assumed that users had good reasons for their Perl config, and we shouldn't override it unless absolutely necessary.

I agree with Michael that having 5.24 build the newer YAML is the better solution.

[mherger]

Happy to merge the change. But neither summary nor description of the change have anything left to do with the final change :-). Could you please update - or submit a new change request?

[mw9]

I was in the process of doing that - struggling with git. 😄 Better now ? (Assuming I haven't broken it...)

[mherger]

Ahm... I don't see any difference... It's probably easiest to drop this request and submit a new one. It happens :-).

[mw9]

Done. Fingers crossed. I must educate myself on the intricacies of this malarkey.