Ævar Arnfjörð Bjarmason <[email protected]> wrote:
> On Mon, May 27 2019, Eric Wong wrote:
> > Chris Mayo <[email protected]> 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 started writing this earlier, but dropped my connection.
And brian said the same thing I was going to say.
If OS packagers were to start making Net::SMTP/Net::Domain
optional (which I sorta expect...), we should make them
optional, too (and add descriptive error messages and manpage
updates).
I have no need for Net::SMTP with sendemail.smtpserver=/usr/bin/msmtp
> 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).
Too soon for the fallback code removal; maybe when CentOS 6 is
EOL.... However, the "->can" check is nicer, yes.
> 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 prefer we check options passed to the program and decide
which dependencies to require based on that. The manpage and
--help could be listing the modules required for certain option
groups, even.
> I wouldn't say the same thing about git-add--interactive.perl due to
> more common its use is.
I wish to see git-send-email (and vendor-neutral messaging in
general) gain more traction. IMHO, send-email should reach the
commonality of other parts of git.
(*) if/when I find the time, I'd make "git svn find-rev"
work w/o SVN::Perl, too.
