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

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

On Mon, May 27 2019, Eric Wong wrote:

> Chris Mayo <aklhfex@gmail.com> wrote:
>> git-send-email uses the TLS support in the Net::SMTP core module from
>> recent versions of Perl. Documenting the minimum version is complex
>> because of separate numbering for Perl (5.21.5~169), Net:SMTP (2.34)
>> and libnet (3.01). Version numbers from commit:
>> bfbfc9a953 ("send-email: Net::SMTP::starttls was introduced in v2.34",
>> 2017-05-31)
>
> No disagreement for removing the doc requirement for Net::SMTP::SSL.
>
> But core modules can be split out by OS packagers.  For
> Fedora/RH-based systems, the trend tends to be increasing
> granularity and having more optional packages.
>
> So I think documenting Net::SMTP (and Net::Domain) as
> requirements would still be good, perhaps with a note stating
> they're typically installed with Perl.
>
> Fwiw, I recently ran into some issues where core modules such as
> Devel::Peek, Encode, and autodie were separate packages on CentOS 7.

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?

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.

That would take care of the communication about module dependencies via
manpage problem since we'd error by default. When I package things I
much prefer that error mode to "parts of package silently don't work
because we check at runtime and I didn't religiously scour the
docs/release notes".

I wouldn't say the same thing about git-add--interactive.perl due to
more common its use is.