Jeff King <p...@peff.net> writes: > On Tue, Dec 19, 2017 at 09:08:44AM -0800, Junio C Hamano wrote: > >> Jeff King <p...@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.
