* Alex Elsayed (eternal...@gmail.com) [090528 22:17]: > While lurking in IRC, I've seen several discussions of what CPAN 6 should > look like.
I would really like to see a split in terminology being used for the various seperate problems. The traditional confusion about what CPAN is: an archive or an install tool. Package manager discussions are in the process AFTER the install tool: to distribute OS changes to be made. In the messages on the list, I see people merge requirements of these very independent tasks. I think that package managers are not a "CPAN" related problem at all. The Perl install tool decides which files it wants to have within some file-system tree and versioned environment, and then package managers distribute those files and meta-data. Also, there are various different package managers around for Linux distributions, and they tend to be replaced every few years. If you want people to use Perl modules on their Linux systems in a convenient way, you have to distribute each perl module in all of the existing formats. Of course, a tool like "alien" can be used to simplify the task of creating all these flavors. IMO, that discussion should go in the direction of additional services: the CPAN archive distributes what authors publish. The install tools (CPAN.pm/CPANPLUS/successors) make that code fit in specific operating systems. As a service, other people can publish the results of their specific module installation via package-managers to the world, such that those people can use they platform native software management tools. Just like search.cpan.org is an independent additional service on the CPAN archive. > I personally believe that there are a few requirements for a package format > that is sufficient for Perl 6: > * It must enable packaging for both binary- and source-based distros > * It must enable automatic generation of packages for supported systems > (although it may well not be capable of it out of the box) > * It must permit (or preferably help with) attempts to support new systems > * It must be simple to submit packages in the correct format > * It must enable the design and building of an automatic testing system The worst flaws in software design are based on the idea that you can organize the outside world. The Perl community will never be able to push its packaging mechanism into Linux distributions. We may be able to select the ideal packaging mechanism, and then they will wrap that in their own packaging mechanism. IMO, as Perl community, we should focus on the things we are good in: have people contribute free Perl code in a simple and platform independent way. Let package manager specialists do their job! They will NEVER be satisfied by the choices we make for them. To help package builders do their job simple and correctly, we have to supply them with as good metadata as we can. Which means: . as much as possible (sufficient kwantity) . very explicitly defined structure and content (predictable quality) . added with minimal hassle for the (often lazy) authors of the code (usability) . extensible meta-data structure (future grow path by design) To get these things right is already an increadible amount of work... and no-one else does that for us. There are so many improvements in this area to be made in our current set-up already, which no-one picks up. Does anyone like to see my wishlist? See http://cpan6.org/papers/2008yapceu/ In the last example http://cpan6.org/papers/2008yapceu/cache-release.xml I show much more additional meta-data information than currently provided my Meta.YML, but all very usefull for packaging tools and other services. (I have used XML as syntax, because with XML-schemas I can precisely describe the structure and content: quality!, but you can also transmit the data in YAML, JSON, Data::Dumper,... that is just unimportant syntax!!!) One thing to mention: I have separated some meta-data into own releases as well. For instance, in stead of including all kinds of personal information (like email address) inside the distribution, I let people make a release which contains that information just like a software release. The released software only contains a reference to the personal information. That means that people can upgrade their personal information (make a new release of themselves) when the email address changes. Of course, that exact content of "personal information" is not an Perl6 issue, but it is solved in my CPAN6. PACKAGING IS NOT OUR BALLGAME!!! -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net