On Tue, May 28 2019, brian m. carlson wrote: > 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. Just because a package X needs dependency Y at version Z doesn't mean you need to package it up in such a way that everything that needs any version of Y must use it at version Z, you put the two versions in different places on the FS. So in this case the packager would grumble a bit and package up a Net::SMTP installed at another path. I do that myself to get some more modern versions of dependencies on CentOS 6 without breaking the base system. Does that mean we should do it in this case? No, and given the feedback in this thread about this in particular I think we should just keep the old code. But I think is important to clarify in general, i.e. just because you're on CentOS 6 and don't want to update the main perl-Net-SMTP you can still package up a for-git-perl-Net-SMTP or whatever. We had a similar discussion about whether to depend on a more recent libcurl in the past: https://public-inbox.org/git/CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@xxxxxxxxxxxxxx/ > 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. What I was suggesting was whether it was worth it to ask distributors to drop in a few *.pm files, and perhaps a *.so or two compiled against openssl, they wouldn't need to change the base /usr/bin/perl. In the case of the *.pm stuff we could drop fallbacks into perl/Git/LoadCPAN if we wanted things to work out of the box. >> 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'm sympathetic to packagers that do that, particularly when "add -i" and friends in s/Perl/C/ land, at which point we'd be asking some distributors who otherwise wouldn't have perl at all to install it just for us. It seems packagers mainly had issues with the Perl-SSL stuff. We already support SSL for https via libcurl usually, perhaps we'd be better off having some wrapper using that (https://curl.haxx.se/libcurl/c/smtp-tls.html), or having git-send-email.perl support something simpler like say stunnel. > I understand and am fine with splitting components out into multiple > packages or omitting parts interfacing with other systems (e.g. > git-svn). I tend to think of SVN as a system more closely related to Git than Git is related to E-Mail :) It's also something that's by definition part of an "egress" workflow, so it tends to be much easier to work around it being missing than say "add -i" or something you truly need locally not being there.
