tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Perl5 update

I am NOT proposing a mechanism that will find out that Foo::Bar::Bar 
is provided by devel/p5-Foo-Bar.
I repeat: I am NOT proposing an automated mapping from Module names to 
pkgsrc packages.
Did I mention that I DON'T want to automatically decide which pkgsrc 
package a given (non-Core) Perl Module resides in?

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

EF> You could even automatically add a CONFLICTS+= p5-Foo-Bar if you take 
EF> Foo::Bar from Core.
JR> Installing two applications in the same pkgsrc-prefix - one requires 
JR> Foo::Bar 47.11 (in Core), the other Foo::Bar 47::17 - conflicts will 
JR> prevent 2nd app being installed.
You may omit that part, but recording no conflict may prevent one of them 
to work properly, doesn't it?

JR> My question is: what do you want to reach with that proposal?
I guess I tried to explain that before.
1. Currently, when I pkgsrc a Perl Distribution, I have to manually 
   go through all the required modules and find out since which release 
   of Perl they have been in Core. Then, for every module in Core, 
   I have to include a line
        DEPENDS+= {perl>=5.nn,p5-Foo-Bar>=1.23}:../../devel/p5-Foo-Bar
        DEPENDS+= p5-Foo-Bar>=1.23:../../devel/p5-Foo-Bar
   in the Makefile. I nail down the result of my research given what 
   I know about Perl releases up to now.
2. When a new release of Perl adds/removes modules to/from Core, someone 
   has to re-visit all the Makefiles and go through the same dance again.
(3. I prefer to express what I mean, not something that amounts to the same 
 thing under current circumstances.)

If I was allowed to replace the above with something like
        PERL_MODULE_DEPENDS+= Foo::Bar>=1.23;devel/p5-Foo-Bar
(I would like to point out there's a pkrsrc package name "devel/p5-Foo-Bar" 
in that line) then a computer can make these decisions.
Not only are computers better at making bulk decisions, it also allows 
to automatically re-make that decision for every Perl release to come.

> In real world perl modules move between distributions (resulting in 
> different packages)
Yes. Both the current DEPENDS+= way and the way I propose you have to 
manually adjust all Makefiles depending on a module that moves from one 
package to another. I did mention that I don't want to automate the way 
you find out which pkgsrc package or Perl Distribution a given (non-Core) 
module resides in?

Home | Main Index | Thread Index | Old Index