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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 27, 2019, 20:36 UTC
Message-ID: <87imtvmy7f.fsf@evledraar.gmail.com>
In-Reply-To: <20190527193517.GA22013@dcvr>

On Mon, May 27 2019, Eric Wong wrote:

Show 20 quoted lines

> 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.