* Daniel Carrera (daniel.carr...@theingots.org) [090528 14:18]: > There was some talk on IRC about a new version of CPAN to match the new > version of Perl.
In March 2006, Sam Vilain and I started to think about a new CPAN what we named CPAN6. There is a lot of information about the project on http://cpan6.org You can see there that a lot of work has been doen. Core Perl people did really discourage me by continuously debating about the name of the project, instead of helping to implement it. But now other people start to wake up, it might get back on track. > Recap: wayland76 wants to integrate CPAN with the local package manager > (RPM, DEB). He proposed using Software::Package for that (which is > incomplete). Be aware that there are confusing entanglements in the current set-up. Firstly, you have the CPAN archive, which uses "Pause" as entry point and ftp-servers to distribute the accepted "distributions". Secondly, you need local configuration tools to get distributions installed on the right spot. That differs per platform. And sometimes people install for instance under usernames, not system-wide. This is the playfield of CPAN.pm and CPANPLUS. For instance compiling XS, discovering libraries, ... Then, you have the administration on what is installed. Basically, that is what RPM/DEB packages think is interesting. CPAN6 is a possible alternative to the first (the CPAN archive), but improving on the second by allowing advanced (server side) searches. Perl's installation tools have a very limited knowledge... much less than search.cpan.org. > A) Can we add "version", "target" flags to CPAN metadata? I was thinking > that current modules would all be version=1 and target=perl5. CPAN does not have an official concept of version numbers on distributions, but only on the pm files which are inside the distribution. The 02packages list which is used to lookup dependencies converts pm-file $VERSION into distribution names which "accidentally" contain a number. The problem is more serious. Perl6 installation needs to have multiple versions of the same module installed in parallel (and even run within the same program!). So the whole concept of installation has to change into something more modern. > D) In addition to target=perl5 and target=perl6 we could have target=parrot. IMO, we need many more. What you call "target" is actually a namespace. The current CPAN archive has only one target. But with Perl6, we have a need for perl6 distributions, but also the pre-compiled versions of these modules, for PIR, pasm, pieton, and whatever languages we will develop based on Parrot. And... maybe deb and rpm archives which (semi-)automatically provide repackaged versions of modules which arrive in the perl6 archive. CPAN6 can do all that in a rather simple way. > 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). CPAN6's opinion: it distributes releases (Perl5 terminologie: a distribution) which simply is a set of files. During transport, they may get packed together (with f.i. tar) and compressed (with f.i. gzip), but that is unimportant. Whether only a single file is shipped (like a single tar.gz prepared by the author) or many does not matter. So: a minimal installation tool does not need Archive::Tar and a zillion of other core modules in my design. > F) In summary, we have a possible course of action: There is a lot more structurally problematic. Please read one of my papers on the cpan6.org website. I am looking forward to meet people who have read my design documents, and understand that there is more to it than "let's discuss about the project name". There is at least 40k lines of Perl code already waiting to be used for this task. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
