Perl 6 poses a new challenge on the distribution format for Modules. At first, because this modules may be written in a variable set of languages and they may use implementation-specific features that are not "STD Perl 6". That brings us the following two concepts:
This defines which runtimes can run this module, it refers to all Perl 6 implementations (Pugs, Parrot, KP6, SMOP, v6-alpha). This may relate to the fact that this module uses a feature that is only present on this specific implementation. On the other hand, a module may define "runtime: any" to mean that the module uses strict STD Perl 6.
This defines in which architectures this module can be built. This should refer to the arch triplet (i686-linux-gnu, i386-win32???, i386-linux-uclibc) and the build software must be able to realise about compatibilities. When a module is linux related but still independent of cpu and libc implementation, it can use any-linux-any. When a module is compatible with all architectures it may simply have "arch: any".
In order to keep track of installed modules and files, it's important that the module should build a binary package before instalation. While the source package may have "runtime: any" and "arch: any", the resulting binary package will be specific to the runtime that compiled it, and eventually it will be specific to the host architecture (if the build process results in architecture-dependent files).
One of the expected features of Perl 6 is the support of having different versions of the same module installed at the same time. This should be doable easily considering the existance of binary packages that will simply generate a different installation path that would include the versioning information. But on the other hand, sometimes a version is just a minor version that should always replace a previous version. That leads us to the major and minor versioning. A module version is then 0.0-1 where the number after "-" is the minor version.
The source package is a .tar.gz file with mandatory README, copyright and META.yaml file, while the YAML file must have the following layout (dumb representation here):
Each runtime implementation must support building the binary package from the generic source format using its own tools. For instance, parrot might need to build the bytecode for the modules, smop might need to compile some lowlevel C implementations for that module etc.
That relates to each of the types, where
Where 'depends' may be replaced by all types of relationships.
The names of the modules are the names that will be used to import the module. If the module will be called with some namespace prefix, like perl5:Foo or python:Bar, then the name of the module should include this prefix. Otherwise it's understood that the module will be available using that name independent of the language its implemented on. The responsability of the runtime to make sure that is sane during build. For instance, modules implemented in Python may be compiled and made available as if they were implemented in Perl.