* Daniel Ruoso (dan...@ruoso.com) [081217 13:19]: > 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.
>From all the messages of yesterday on the list, this one comes closest to my developments. > 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. For three years now, I work on CPAN6 (http://cpan6.org). However, my spare time is so limited lately that not much progress can be reported. (I may get some help from the changes in the economy soon ;-) > 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. 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 Where do we leave all these other Parrot languages: pre-compiled Perl6, Piethon, etc. Enforce a name-prefix in CPAN? These worries make me start the CPAN6 project. > 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. To overcome this limitation, CPAN6 has an endless amount of CPAN archives (namespaces). A developer can upload a module which he/she wants to share, and other people can run all kinds of services to repackage the data and release it into other archives, for instance: - perl6 source - perl6 precompiled pir - perl6 documentation only - perl6 tests only - perl6 cpantesters results - perl6 rpms - perl6 deb - perl6 deb precompiled pir Additional to the traditional modules relations, we have defined the "derived from". So, when I release a module "My-Module" version "123" into archive "perl6 source", then after a while all kinds of service providers will enrich that data, releasing a "My-Module" version "123" into their own output archives. These services produce different "views" on the original data, each view with its own seperate archive. One trap of S22 is to say: "let's try to do our best for ... (Debian)", because there may be many other distributions or applications frustrated by those choices. Would you change your own structure when the distribution builder changes its ideas? Like SuSE already did three times? The only healthy path is to organize your own data (especially the meta-data) as cleanly as possible, prepared for your own future extension plans. > 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. 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. Basically, CPAN6 does not have the slightest idea what the releases are, as long as some crucial meta-data is provided to make searching possible. I wrote a script which converts any real-life perl5 package into those needs in about two hours. (example output with very strict XML schema: http://cpan6.org/papers/2008yapceu/cache-release.xml) So, for that matter, we do not care about the actual results of 6PAN, as long as the meta-data which is collected is well defined. S22 should at least split into "the distribution, CPAN part", the "package structure, CPAN.pm installation part", and the "convert into other installation tools" part. Interested? Have a look at the website http://cpan6.org There are some papers and presentation from various YAPCs, for instance the relatively global level http://cpan6.org/papers/2008yapceu/ There is a lot of code on my disk (unreleased), and Log::Report and XML::Compile are the most important released general purpose components for the moment. A few more to follow. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
