Em Qua, 2008-12-17 às 23:35 +1100, Timothy S. Nelson escreveu: > On Wed, 17 Dec 2008, Daniel Ruoso wrote: > > Em Qua, 2008-12-17 às 15:00 +1100, Timothy S. Nelson escreveu: > >> My basic assumption is that there's going to be some kind of packaging > >> system written around 6PAN. > > Please take a look in some notes I've written some time ago: > > http://www.perlfoundation.org/perl6/index.cgi?DistributionFormat > I guess I should also say that I'm assuming everyone has at least a > vague familiarity with this: > http://svn.pugscode.org/pugs/docs/Perl6/Spec/S22-cpan.pod > In particular, I'm not sure that Daniel's ideas align with the Draft > S22; I'm hoping Daniel will take a moment to see if they align.
Indeed, for some reason I missed that document. But it's not entirely unaligned. The major difference seems to be having different packages for "source" and "binary" (or "source" and "installable", as in S22). S22 mentions the difference, but doesn't split them in different packages. The most important argument, IMHO, to have them as different packages is to allow a "binary"/"installable" distribution without the need to recompile every module when installing. This should help when you have a target OS that is installed in several machines, then you can re-use the "binary"/"installable" package repository for that specific OS/version. It also allows one source package to generate different binary packages (for instance, having scripts, libs and docs splitted), and makes it easier to do an uninstall, because a "binary"/"installable" package would have a fixed list of files. One thing that is mostly aligned, is the idea that the building of the package is external to it, no more Makefile.PL or Build.PL. The package only lists metadata of which type of things it has, and the running system should realize how to build and install them. Althought, in my notes, I expanded the meaning of it a bit more. In summary, I think inheriting most of the concepts from Debian is something almost consensual, and there's much alignment in both documents in that respect. It would probably make sense to refactor S22 into a more spec-like document. daniel
