Front page | perl.perl6.language |
Postings from May 2009
Re: CPAN -- moving forward
From: Daniel Ruoso
May 30, 2009 15:49
Re: CPAN -- moving forward
Message ID: 1243723889.32634.33.camel@cajueiro
Em Sáb, 2009-05-30 às 22:54 +0200, Daniel Carrera escreveu:
> In the hopes of helping the CPAN discussion move forward, in the
> direction of tangible work, I have made a wiki page with a proposal:
> Please read the "Basics" section, which is quite short. The main point
> of this section is to divide the issue into three parts:
The leap you make from the source package to the different binary
formats is overlooking a lot of details. It would be interesting if you
could take a look in the previous discussions on the matter.
> 1) A package format.
This is supposed to be a source format, but different from current model
used in CPAN, it's pretty clear already that it can't include a "build
system", like ExtUtils::MakeMaker or Module::Install.
There's already some consensus that this "source package" format should
describe what it contains, not how it should be built or installed. For
instance, it should only say something like "in the lib directory
there's a set of STD Perl 6 modules that don't require any low-level
> 2) A low-level install tool, analogous to rpm or dpkg, that converts the
> package (2) into a local package format (rpm, deb, ebuild).
2.0) Build tool
Before installing it, you need to create a "installable package", or
"binary package" (that's what CPAN plus does today). The thing here is
that the process of transforming the "source package" into an
"installable package" will be specific to the Perl implementation, to
the Operating System and to the vendor of the Operating system.
That basically means "it's implementation specific", and each
implementation should do its best to provide that support. For instance,
rakudo might want to compile the modules to Parrot Bytecode, while
mildew might want to compile down some things to C.
If you're in an OS that provides a rich package management system, it
means you can generate native packages, otherwise you need to implement
the next step as well, which is:
2.5) Install tool
In systems where we don't generate native packages, we need a package
manager on our own. It should be capable of taking any "installable
package" and making it available in the system, checking all
dependencies and other requirements..
> 3) A high-level install tool, analogous to yum or apt, that uses the
> CPAN network and resolves dependencies.
I do think this is very much implementation-specific, for instance, in
Debian, with little work you could simply use apt-build to get your
packages built and available for installation with apt-get.
The part 1 is really the critical issue, 2.0, 2.5 and 3 are mostly
implementation specific and are considerably easier to adapt than the
things in the part 1. We do need to find a very solid way of describing
what the package contains in order that implementation-specific build
tools can make them work.