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
or
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