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.
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.
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.
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.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
