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 extension. 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 systems * Encourage use of pure-P6 filters, so as to enable cross-distro mantainership * 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 Comments?