On Tue, Dec 12 2017, Alex Bennée jotted:

> Thomas Adam <tho...@xteddy.org> writes:
>
>> Hi,
>>
>> On Mon, Dec 11, 2017 at 08:46:46PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>> I.e. we'd just ship a copy of Email::Valid and Mail::Address in
>>> perl/Git/FromCPAN/, use a wrapper to load them, and then we wouldn't
>>> need to if/else this at the code level, just always use the module,
>>> and it would work even on core perl.
>>
>> I disagree with the premise of this, Ævar.  As soon as you go down this 
>> route,
>> it increases maintenance to ensure we keep up to date with what's on CPAN for
>> a tiny edge-case which I don't believe exists.
>>
>> You may as well just use App::FatPacker.
>>
>> We're talking about package maintenance here -- and as I said before, there's
>> plenty of it around.  For those distributions which ship Git (and hence also
>> package git-send-email), the dependencies are already there, too.  I just
>> cannot see this being a problem in relying on non-core perl modules.  Every
>> perl program does this, and they don't go down this route of having copies of
>> various CPAN modules just in case.  So why should we?  We're not a special
>> snowflake.
>
> I less bothered my the potentially shipping a git specific copy than
> ensuring the packagers pick up the dependency when they do their builds.
> Do we already have a mechanism for testing for non-core perl modules
> during the "configure" phase of git?

Current git.git master does two things:

 * For Error.pm we test at build time. See `git grep Error --
   'perl/Make*'`. If you don't have Error.pm when you build we'll ship
   an old copy of it, and use that forever even if it's installed from
   CPAN afterwards.

 * For Mail::Address, Net::Domain etc. we don't ship the CPAN module,
   but some fallback code. We test at runtime, see `git grep
   eval.*require`. If you install the package from CPAN we'll start
   using it at your next invocation.

My "Makefile: replace perl/Makefile.PL with simple make rules" currently
cooking in pu changes that so that:

 * We always at runtime test for the system CPAN module.

 * In the case of Error.pm we happen to ship a fallback, in the case of
   Mail::Address etc. we don't and have fallback code, but we could also
   just ship a copy and remove the fallback code.

This makes more sense, we always "dynamically link" as it were, we'll
just change the target to (a presumably newer) system module in the case
of Error.pm if it's found on the system, otherwise use our fallback.

Reply via email to