On Sun, Dec 23 2018, brian m. carlson wrote:
> On Sun, Dec 23, 2018 at 11:05:46PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, Dec 21 2018, brian m. carlson wrote:
>> > How do git send-email and git svn work in such a case? They depend on
>> > the Git and Git::SVN modules being in place, so if you use a Perl other
>> > than the one you built Git with, they won't be present (or they'll be
>> > present, but potentially with the wrong version).
>>
>> Yeah this is one of the things I was alluding to in
>> <87a7l1fx8x.fsf@xxxxxxxxxxxxxxxxxxx>.
>>
>> We don't ship any C bindings, so our libs end up in
>> e.g. /usr/share/perl5, some custom-built perls will have that in their
>> @INC still, no idea if any of this OSX stuff does.
>>
>> But otherwise we'd either need to give the user a way to override
>> PERL5LIB (or they can do it themselves...), or better yet continue what
>> I started in 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple
>> make rules", 2017-12-10) and make our perl stuff entirely decoupled from
>> the system install.
>>
>> E.g. Linux distros would probably still override that and install our
>> *.pm stuff in their usual Perl places, but by default we could just have
>> a libexec/perl directory with all this stuff, and find our libraries
>> there, then it won't matter if we chainload to a new Perl interpreter,
>> we'll still find the libs in the same place.
>
> This wouldn't fix the fact that we still need modules like Net::SMTP,
> Authen::SASL, and IO::Socket::SSL (because these days every provider
> forces TLS on the submission port). Since those are going to come from
> the distributor, letting people override the Perl path to some arbitrary
> path will mean that those modules may not be installed.
Yeah, but my reading (which may be wrong) of John Passaro's E-Mail
upthread
(<CAJdN7Kioa22xrDP2ssZXmBbu7KDkcr2MQCUDW=Tzm5ydzeChBQ@xxxxxxxxxxxxxx>)
is that for some users this is the path of least resistance to getting
git-send-email et al working for whatever reason.
I.e. they'd like to install a git version that's compiled against
/usr/bin/perl, and then after the fact ask git to point to some other
better working perl installation with all of the above compiled.
> I also think that the situation you want with relocatable modules is
> only going to be useful for people who custom-install their own Git,
> which is not most people. Nobody shipping a packaged version of Git is
> going to install modules in a custom Git-specific path (since they can't
> be loaded by other software), so everyone who want to use a custom Perl
> will already be compiling a custom Git and can just specify the Perl
> they want to use.
I mean that we could just make RUNTIME_PREFIX our default behavior, it
would simplify things by only carrying one "how do we find stuff" mode,
and in this case nicely solve this whole problem of your custom perl not
having git's perl modules in its @INC (but having everything else,
e.g. Authen::SASL available).
> My concern is, more generally, that this situation is going to lead to
> hard-to-troubleshoot user support issues. I routinely answer questions
> on Stack Overflow and I see all sorts of cases where users who may be
> great programmers but are mostly unfamiliar with Git end up in bad
> situations.
>
> For example, at a previous job, we shipped a newer Git and Perl, which
> were installed in a custom path (so definitely not using relocatable
> modules). If this option were enabled and user used the newer Git, which
> was installed in a custom path, but the system Perl, things would
> definitely be broken, since the system Perl would almost certainly have
> none of the right modules (or, if it did, they'd be grossly out of
> date). A lot of the users who would run into this issue are less
> technical, and so wouldn't know how to fix it.
No comment on this other than: "whoever's itch this actually is and who
picks up my POC patch will need to address this to brian's satisfaction"
:)
> We've traditionally shied away from specifying things like
> "#!/usr/bin/env perl" specifically for this reason: because people will
> often have custom-compiled versions of interpreters that don't meet our
> needs. I'm not seeing how this is significantly different.
Because "#!/usr/bin/env perl" would break git if you were just playing
around with a custom perl for some other reason, e.g. perl web
development. I agree that this wouldn't be acceptable (as see in my
https://public-inbox.org/git/878t55qga6.fsf@xxxxxxxxxxxxxxxxxxx/ that
John linked to).
Whereas what's being proposed here is some way to specifically tell git
via configuration that it should use a runtime configured perl instead
of the compile-time one.
