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?
