While lurking in IRC, I've seen several discussions of what CPAN 6 should 
look like. Honestly, wayland76++'s idea for packaging seems the best to me. 
Most of the suggestions so far, especially those based on alien, apt, yum, 
or other existing package managers have a few major problems:

* Alien only converts between a few package formats
* All of these suggestions are _heavily_ biased towards binary distributions
* These suggestions make automatic packaging for new distros extremely 
difficult, because they require major changes to multiple projects

For example, let's take Gentoo or Exherbo. Gentoo has two package managers, 
one which is used by most Gentoo users (Portage) and one which is more 
featureful and advances faster (for various reasons, including more 
developers) (Paludis). Portage supports binary packages through .tbz2 files 
with trailing metadata. Paludis does not support these, as they have been 
deemed ill-conceived and poorly implemented by the lead developer, and is 
working on its own binary package system. Exherbo uses Paludis exclusively. 
Both distros are source-based.

Paludis has a tool which can import arbitrary trees to merge into the 
filesystem, but it's generally preferred that it be used only by users, not 
system packagers.

Portage has no such tool.

One existing problem for Gentoo is supporting installation of Perl 5 
modules. Because all metadata is spread out (and more importantly, /inside/ 
the tarballs), it is impossible to, say, add a new kind of repository for 
Perl modules - you'd have to have the full source for every module on your 
machine. Similarly, the automatic ebuild creator for P5 modules, g-cpan, is 
forced to recursively download packages, unpack them, and read their 
metadata before fetching their dependencies. This poses a significant 
problem for distros which mandate up-front configuration without an 
interactivity requirement (i.e., Exherbo and to a lesser degree Gentoo).

I think that wayland76++'s idea of having a common metadata system with 
filters to convert that metadata into a distribution package is the best 
currently-proposed solution, but I also feel that it needs some additional 

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

My extensions to wayland76++'s proposal are as follows:

* Include in the metadata enough information to:
    * Build a binary package ( deb, rpm, etc)
    * Create a source build script ( ebuild, exheres, PKGBUILD, etc)
    * Fetch the source package
    * Contact maintainer/author/etc with issues
    * Query stability information
    * Prod the testing framework (not the actual tests, though)
* Separate the metadata from the package
    * If the metadata is in the source distribution, have CPAN 6 extract it, 
and put it in a separate tree of just metadata
    * This enables simple fetching of the entire /metadata/ tree without the 
entire /source/ tree
    * Also opens the door to package managers natively supporting this 
format (Paludis has done this with CRAN and is working on Ruby Gems support)
* Have well-documented example filters, and a skeleton-filter-builder script
    * Enables packaging developers to rapidly roll out support for new 
* Encourage use of pure-P6 filters, so as to enable cross-distro 
    * Like building Fedora packages on the developer's Debian workstation
* Multiple submission avenues
    * Simple login-controlled FTP
    * Web submission
    * PAUSE-like client
    * Hosted SCM source w/tagging


Reply via email to