Re: [RFC PATCH 0/2] contrib/credential/netrc Makefile & test improvements

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 10, 2018, 08:36 UTC
Message-ID: <87efhfvxzu.fsf@evledraar.gmail.com>
In-Reply-To: <20180610022802.GX3094@zaya.teonanacatl.net>

On Sun, Jun 10 2018, Todd Zullinger wrote:

Show 16 quoted lines

>> I added 'use autodie;' without realizing it had external dependencies.
>> According to the documentation
>> http://perldoc.perl.org/autodie.html
>> it's a pragma since perl 5.10.1
>> Removing 'use autodie;' should be fine: it's not critical.
>
> I should clarify that part of why autodie isn't in my build
> environment is that the Fedora and RHEL7+ perl packages
> split out many modules which are shipped as part of the core
> perl tarball.  So while all the platforms I care about have
> perl >= 5.10.1, the Fedora and newer RHEL systems have the
> autodie module in a separate package.
>
> That said, the INSTALL docs still suggest that we only
> require perl >= 5.8, so if autodie is easily removed, that
> would probably be a good plan.

The intent of those docs was and still is to say "5.8 and the modules it ships with".

This was discussed when 2.17.0 was released with my changes to make us unconditionally use Digest::MD5: https://public-inbox.org/git/87fu50e0ht.fsf@evledraar.gmail.com/

As noted there that's not some dogmatic "RedHat altered perl so we don't care about them", but rather that in practice this doesn't impact users negatively, so I think it's fine.

Show 6 quoted lines

> Ævar brought up bumping the minimum supported perl to 5.10.0
> last December, in <20171223174400.26668-1-avarab@gmail.com>
> (https://public-inbox.org/git/20171223174400.26668-1-avarab@gmail.com/).
> The general consensus seemed positive, but I don't think
> it's happened.  Even so, that was 5.10.0, not the 5.10.1
> which added autodie.

Right, this doesn't apply to autodie. Looking at https://www.cpan.org/ports/binaries.html there were a lot of releases that had 5.10.0, not *.1.

Also git-credential-netrc is in contrib, I don't know if that warrants treating it differently, I don't use it myself, and don't know how much it's "not really contrib" in practice (e.g. like the bash completion which is installed everywhere...)>

But yeah, skimming the code it would be easy to remove the dependency.