git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Eric Wong <e@80x24.org>, Chris Mayo <aklhfex@gmail.com>,
	git@vger.kernel.org, git-packagers@googlegroups.com,
	Dennis Kaarsemaker <dennis@kaarsemaker.net>
Subject: Re: [PATCH] send-email: remove documented requirement for Net::SMTP::SSL
Date: Mon, 27 May 2019 23:43:47 +0000	[thread overview]
Message-ID: <20190527234347.GH8616@genre.crustytoothpaste.net> (raw)
In-Reply-To: <87imtvmy7f.fsf@evledraar.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

  reply	other threads:[~2019-05-27 23:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-26 17:22 [PATCH] send-email: remove documented requirement for Net::SMTP::SSL Chris Mayo
2019-05-27 19:35 ` Eric Wong
2019-05-27 20:36   ` Ævar Arnfjörð Bjarmason
2019-05-27 23:43     ` brian m. carlson [this message]
2019-05-28  2:17       ` Ævar Arnfjörð Bjarmason
2019-05-28  1:22     ` Eric Wong
2019-05-28  0:05   ` Todd Zullinger
2019-05-28  1:31     ` Eric Wong
2019-05-28  1:43       ` Ævar Arnfjörð Bjarmason
2019-05-28  1:56         ` Todd Zullinger
2019-05-28  1:57         ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190527234347.GH8616@genre.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=aklhfex@gmail.com \
    --cc=avarab@gmail.com \
    --cc=dennis@kaarsemaker.net \
    --cc=e@80x24.org \
    --cc=git-packagers@googlegroups.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).