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.

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.

> 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 understand and am fine with splitting components out into multiple
packages or omitting parts interfacing with other systems (e.g.
git-svn).
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204