Re: difftool uses hardcoded perl shebang

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 19, 2017, 17:47 UTC
Message-ID: <xmqqd13awqxx.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20171219171253.GA7526@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 20 quoted lines

> On Tue, Dec 19, 2017 at 09:08:44AM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > In the meantime, pointing to the actual build-time perl is a workaround
>> > (but obviously not if it's being done by a third-party packager who has
>> > no idea where your perl is).
>> 
>> Is such a binary packaging scheme actually in use that deliberately
>> leaves it up to the end user where/if a perl is installed and if it
>> is an appropriately recent version?  It sounds rather irresponsible
>> to me.
>
> No, I mean that the user can do:
>
>   make PERL_PATH=/path/to/perl/in/my/PATH
>
> but if they are not building Git themselves, that is not an option for
> them. And a binary packager cannot help them there, because they do not
> know that path.

I think we are saying the same thing. A third-party binary packager cannot guess where your custom Perl is nor if it is recent enough. I just was wondering if such an irresponsible packaging scheme is in use that lets you install Git without somehow making sure that the box also has a version of Perl that can be used with the version of Git. Then the presence of /path/to/perl/in/my/PATH does not matter, as it does not have to be used with Git.