Em Qui, 2009-05-28 às 16:18 +0200, Daniel Carrera escreveu:
> Hello all,
> There was some talk on IRC about a new version of CPAN to match the new 
> version of Perl.

I just wanted to point out some previous conclusion on this issue.

What currently we generically name "CPAN" is actually composed of:

 1 - A repository for source archives
 2 - A build-system (ExtUtils::MAkeMaker, Module::Build)

For Perl 6, there is already some kind of consensus that we need an
architecture that goes in the following lines

 1 - A repository for source archives (that's markov's CPAN6)
 2 - An abstract representation for the source's metadata (describing
what the archive has, instead of how to build and install)
 3 - A per-implementation per-architecture infra-estructure that knows
how to take this abstract metadata and build a "installable" package
(for that implementation and architecture)
 4 - A per-implementation per-architecture package manager (in some
cases the native package manager can be used) that install and handles
dependencies of "installable" packages.

So, a regular scenario would look like:

 1 - You search for something, find Some::Module and download
Some-Module-0.1.tar.gz it from CPAN6

 2 - Some-Module-0.1.tar.gz contains a META.yml like file containing a
description of what composes this archive

 3 - You run "rakudo-build Some-Module-0.1.tar.gz" if you're in rakudo
or "smop-build Some-Module-0.1.tar.gz" if you're in smop. If you're in a
Debian machine that should build libsome-module-parrot_0.1_i386.deb or

 4 - As in the Debian case, you would use the native package manager,
you could simply apt-get install libsome-module-rakudo (considering the
above step put the file in a local repo, as apt-build does today). If
you're in Win32, a package manager is probably going to written so you
can install the 'installable' package in a similar manner.


Reply via email to