On Wed, Dec 17, 2008 at 10:19:07AM -0300, Daniel Ruoso wrote: > 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.
I am sticking my neck out here, but don't forget that there are a multitude of package management systems out there, including FreeBSD's Ports /and/ Packages. A "packages" is probably more in line with where this discussion seems to be heading, but I wanted to mention both. Packages and Ports contain *a lot* of Perl modules, and although I have zero experience actually putting a Perl module into Ports or creating a Package (and dealing with the dependencies), the more easily this process could be automated against a 6PAN module, the better. Cheers, Brett > > daniel >
