* 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.


       Mark Overmeer MSc                                MARKOV Solutions
       m...@overmeer.net                          soluti...@overmeer.net
http://Mark.Overmeer.net                   http://solutions.overmeer.net

Reply via email to