Em Qui, 2008-12-18 às 11:38 +0100, Mark Overmeer escreveu: > In the current state of affairs, CPAN is limited to Perl5 and strongely > entangled by Perl5 install tools. Do we want to have people install > Perl5 on their (maybe small) machine before they can install Perl6 stuff? > Rpm-tools and deb-tools are simply alternatives to CPAN.pm
I presume the release of (whichever implementation of) Perl 6 should have deployed a minimal set of features of this package management, so you can install new modules (which could include build-depends). I even think each implementation might have its own package manager, optimized to its needs, and eventually, a distro might want to deploy a customized version of that package manager (that would build the deb or rpm and install it integrated with the rest of the system-wide package management). In summary, I think CPAN6/6PAN should deal with the content, and not how the content is built/installed. That is specific to each Perl 6 implementation and each OS, and that is the reasoning behind the exclusive use of metadata, instead of an embedded build system. > One trap of S22 is to say: "let's try to do our best for ... > (Debian)", I agree that doing the best for Debian is a bad idea, but I don't think that's the intended in S22 or in the notes I wrote. But some concepts indeed come from the experience Debian has in managing such a diverse universe. > Do realize that getting things installed on a system can be quite hard. > Even much harder to express in an abstract meta-data language. So, for > CPAN6 I decided to strictly seperate the distribution of releases from > the actual content of those releases. That's why I believe the meta-data should describe what the content *is*, and not how it is installed. Deciding how it is installed is completely implementation/OS dependent, and I think should be delegated to the implementation/OS. This will probably mean that we will have some standard way of querying for files included in some distribution, so we make sure the decision of where to store the files is completely up to the implementation and OS. daniel
