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

From: Kang-min Liu <gugod@gugod.org>
Date: Dec 29, 2014, 23:09 UTC
Message-ID: <m2iogujbon.fsf@gugod.org>
In-Reply-To: <54A1C29C.4090100@blackperl.com>

Show 12 quoted lines

> 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