Hello all,
There was some talk on IRC about a new version of CPAN to match the new
version of Perl.
Recap: wayland76 wants to integrate CPAN with the local package manager
(RPM, DEB). He proposed using Software::Package for that (which is
incomplete).
Now some ideas of my own:
A) Can we add "version", "target" flags to CPAN metadata? I was thinking
that current modules would all be version=1 and target=perl5.
B) If we can, we can modify the "cpan" utility to run a different
program depending on the module version:
if (!$version or $version == 1) { system("cpan1 $module"); }
else { system("cpan2 $module"); }
So initially all modules go to the "cpan1" program.
C) With this we are free to make a new CPAN format and a "cpan2" install
script. We can upload the new modules to CPAN and the "cpan" script will
handle them correctly.
In other words: We don't need a new CPAN site. We can have two formats
in the same site. We just need a rule that a module can only depend on
modules with the same format.
Notice that Perl 5 authors can then also start using the new CPAN
format. They'd just set "target=perl5".
All in all, I hope this would ease the migration to the new CPAN format.
D) In addition to target=perl5 and target=perl6 we could have target=parrot.
The CPAN user interface would have to be updated to allow two modules
with the same name but different targets.
E) With all this done, we can talk about the new CPAN package format. We
can use the "alien" utility (written in Perl) to finish the
Software::Package distribution (which currently only supports RPM).
F) In summary, we have a possible course of action:
1. Add "version" and "target" metadata to CPAN.
2. Write to the author of "alien" to see if he'll let us copy his code
under the Perl license.
3. Use "alien" to finish the Software::Package distribution, adding
support for at least DEB.
4. Use these to make a new CPAN format.
5. We can port Software::Package to Perl 6 and package them as a way to
test the new CPAN format with Perl 6.
...
What do you think?
Daniel.
