Re: [PATCH] send-email: remove documented requirement for Net::SMTP::SSL

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, May 28 2019, brian m. carlson wrote:

> On 2019-05-27 at 20:36:36, Ævar Arnfjörð Bjarmason wrote:
>> I've done enough git-send-email patching in anger for a year at least
>> with what's sitting in "next" so I'm not working on this, but just my
>> 0.02:
>>
>> I wonder if we shouldn't just be much more aggressive about version
>> requirements for something like git-send-email.
>>
>> Do we really have git users who want a new git *and* have an old perl
>> *and* aren't just getting it from an OS package where the module is
>> dual-life, so the distributor can just package up the newer version if
>> we were to require it?
>
> In my experience, shipping newer versions of packages shipped with the
> OS is a no-no. That's a great way to break unrelated software on the
> system, and if you're the distributor, to get users angry at you about
> breaking stuff on their systems.

Just because a package X needs dependency Y at version Z doesn't mean
you need to package it up in such a way that everything that needs any
version of Y must use it at version Z, you put the two versions in
different places on the FS.

So in this case the packager would grumble a bit and package up a
Net::SMTP installed at another path. I do that myself to get some more
modern versions of dependencies on CentOS 6 without breaking the base
system.

Does that mean we should do it in this case? No, and given the feedback
in this thread about this in particular I think we should just keep the
old code.

But I think is important to clarify in general, i.e. just because you're
on CentOS 6 and don't want to update the main perl-Net-SMTP you can
still package up a for-git-perl-Net-SMTP or whatever.

We had a similar discussion about whether to depend on a more recent
libcurl in the past:

https://public-inbox.org/git/CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@mail.gmail.com/

> We do indeed have users who want a newer Git on those systems and are
> using the system Perl. The Git shipped with CentOS 7 (not to mention
> CentOS 6) is positively ancient and doesn't support useful features like
> worktrees, so it makes sense to upgrade it. But if you're not a Perl
> shop, nobody cares about the version of Perl on the system and fussing
> with it doesn't make sense.

What I was suggesting was whether it was worth it to ask distributors to
drop in a few *.pm files, and perhaps a *.so or two compiled against
openssl, they wouldn't need to change the base /usr/bin/perl.

In the case of the *.pm stuff we could drop fallbacks into
perl/Git/LoadCPAN if we wanted things to work out of the box.

>> I.e. couldn't we just remove the fallback code added in 0ead000c3a
>> ("send-email: Net::SMTP::SSL is obsolete, use only when necessary",
>> 2017-03-24) and do away with this version detection (which b.t.w. should
>> just do a $obj->can("starttls") check instead).
>>
>> For shipping a newer Net::SMTP we aren't talking about upgrading
>> /usr/bin/perl, just that module, and anyone who's packaging git
>> (e.g. Debian) who cares about minimal dependencies is likely splitting
>> out git-send-email.perl anyway.
>>
>> We could then just add some flag similar to NO_PERL_CPAN_FALLBACKS so
>> we'd error out by default unless these modules were there when git was
>> built, packagers could then still set some "no I can't be bothered with
>> send-email at all" or "no I can't be bothered with its SSL support", in
>> the latter case git-send-email would work except for the SSL parts.
>
> We had a problem with Homebrew sometime back where they stopped shipping
> git-send-email because it required Perl modules and there was a big
> uproar and a request for us to allow dynamic Perl support. I would like
> to discourage distributors from simply refusing to ship core pieces of
> Git because it tends to cause problems for users and for us down the
> line.

I'm sympathetic to packagers that do that, particularly when "add -i"
and friends in s/Perl/C/ land, at which point we'd be asking some
distributors who otherwise wouldn't have perl at all to install it just
for us.

It seems packagers mainly had issues with the Perl-SSL stuff. We already
support SSL for https via libcurl usually, perhaps we'd be better off
having some wrapper using that
(https://curl.haxx.se/libcurl/c/smtp-tls.html), or having
git-send-email.perl support something simpler like say stunnel.

> I understand and am fine with splitting components out into multiple
> packages or omitting parts interfacing with other systems (e.g.
> git-svn).

I tend to think of SVN as a system more closely related to Git than Git
is related to E-Mail :)

It's also something that's by definition part of an "egress" workflow,
so it tends to be much easier to work around it being missing than say
"add -i" or something you truly need locally not being there.