Re: Git's Perl scripts can fail if user is configured for perlbrew

[Kang-min Liu <gugod@gugod.org>]

> On 12/29/14, 7:21 AM, Ævar Arnfjörð Bjarmason wrote:
>> [CC'd the perlbrew author]
>>
>> This is a bit of a tricky issue.
>>
>> Using whatever perl is defined in the environment is just as likely to
>> break, in general the build process tries to pick these assets at
>> compile-time. Imagine you're experimenting with some custom perl
>> version and now Git inexplicably breaks.
>>
>> It's better if Git detects a working perl when you compile it and
>> sticks with that, which is why we use /usr/bin/perl by default.

With "perl" being an external dependency, sticking with whatever at the
compile time basically means these should stick:

- `which perl`, and the same $Config options
- Every module contained in PERL5LIB
- Other external executable dependencies of some .pm files that lives
  somewhere in PATH

We could of course build an app bundle dir like a lightweight container.
to mitigate this... but that would'nt be usefull without tweaking the
shebang line of the scripts -- to point to the perl script (shim or
real) that should be compatible with the newly built git.

I'd argue that trying to compile git (or other stuff in general) against
a perlbrew-managed perl is something that "perlbrew" executable cannot
manage. Because it is both valid that the user is doing this
intentionally and want the outcome, or the user is doing this
unintentionally. And even if we have a shim "perl" script, it would'nt
help as long as it is the "whatever perl" in PATH -- which might just be
incompitble.

I wonder if disabling perlbrew per-building can deal with this:

    'perlbrew off'

If this end up changing the shebang line then maybe, if not then it'll
still intefere after perlbrew is re-activated.

The other option to minimize perlbrew interferince is of course to
completely deprecate the global env var approach and make them project
local. But that's another story.

-- 
Cheers,
Kang-min Liu