[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Perl5 update
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
> 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?
Main Index |
Thread Index |