Re: Perl5 update

[Jens Rehsack <rehsack%gmail.com@localhost>]

Am 03.06.2014 um 15:23 schrieb Edgar Fuß <ef%math.uni-bonn.de@localhost>:

> Shouldn't there be an infrastructure mechanism that allows a Perl Module's 
> Makefile to express either
>       I need Foo::Bar 47.11, and I assume it's in Core
> (which sets PKG_FAIL_REASON if that assertion is false)
> or better
>       I need Foo::Bar 47.11, take it from Core or devel/p5-Foo-Bar
> (adding a dependency on the latter if the former is false)?
> 
> I don't think that would be too hard to implement. You need a pre-digested 
> corelist output in lang/perl5/somewhere, an fgrep and a version comparison.

How about Test::Harness::Env? Separate module or bundled into p5-Test-Harness?

> You could even automatically add a CONFLICTS+= p5-Foo-Bar if you take 
> Foo::Bar from Core.

Installing two applications in the same pkgsrc-prefix - one requires Foo::Bar
47.11 (in Core), the other Foo::Bar 47::17 - conflicts will prevent 2nd app
being installed.

> I guess Perl Module packages automatically depend on 
> "this Perl Version and not the next one", don't tey?
> 
> Do I overlook something?

You think an 80% solution. In real world perl modules move between distributions
(resulting in different packages) - we would have to create a buillink3.mk for
each perl module then - and we have much more issues on updating.

As I said: come to next niederrhein.pm and I explain that in full detail.
I'm working on a cpan-package creator and it's not that trivial you see for
simple modules. Check DBIx::Class, Moose, Catalyst or IO::Async for pitfalls.

My question is: what do you want to reach with that proposal?

Cheers
-- 
Jens Rehsack
rehsack%gmail.com@localhost