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:
Daniel, 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 integration". > 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. In summary, 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. daniel
