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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: May 27, 2019, 23:43 UTC
Message-ID: <20190527234347.GH8616@genre.crustytoothpaste.net>
In-Reply-To: <87imtvmy7f.fsf@evledraar.gmail.com>

On 2019-05-27 at 20:36:36, Ævar Arnfjörð Bjarmason wrote:

Show 11 quoted lines

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

Show 15 quoted lines

> 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