Synopsis 22: Package Format [DRAFT]
Jos Boumans <kane@cpan.org> Audrey Tang <audreyt@audreyt.org> Florian Ragwitz <rafl@debian.org> Tim Nelson <wayland@wayland.id.au>
Created: 3 Nov 2005 Last Modified: 19 Dec 2008 Version: 2
I'll start by listing a few terms, and whether this document is supposed to cover them or not.
.jib files; this is the source package format, and is specified in this document
CPAN6; this is a piece of software for managing an archive network (such as CPAN). This is not specified in this document; see http://cpan6.org/
PAUSE6; this is an actual network based on the cpan6 software (see above). It also is not documented here.
CPAN6.pm; this is a piece of software that starts with what it can get on PAUSE6, and attempts to give you an installed perl module (this is a replacement for CPANPLUS/cpan2dist)
The following can be useful inspirations:
Debian Policy: http://www.us.debian.org/doc/debian-policy
Software::Packager::Metadata: http://perlsoftpackmet.svn.sourceforge.net/viewvc/perlsoftpackmet/main/doc/ (click on the link in the Rev. column next to Overview)
Step 1 of the general flow should ideally be done by an automated tool, like p5's current Module::Starter or somesuch. Suffice to say, it should produce a layout something along these lines (note, this is just an example):
p5-Foo-Bar/ lib/ Foo/ Bar.pm t/ 00_load.t _jib/ META.info
The files in the _jib dir are part of the package metadata. The most important file is the META.info file that holds all the collected metadata about the package, which ideally gets filled (mostly) by what is described in step 2 of the General Flow. Any pre/posthook files should also go in this directory. This directory should be extensible, so new files can be added to extend functionality. See the section on Metadata Spec for details.
General Flow
Metadata Spec
These files are created in step 3 of the General Flow
JIB is a simple 3 letter combination that's not yet 'taken' as a known extension. It's purposely not perl specific, as there's nothing about the JIB specification that's limiting it to perl only.
JIB
# XXX - Also package is carrying double meaning in P6 as both namespace and source distribution. Can we remove the former meaning and refer to them as module and namespace from now on?
package
module
namespace
.jib files are archives designed to distribute source packages, not installable packages. As we will need to compile things on the client side (things that have C bits or equivalent), and because we can not know the install path before hand, a source package is an obvious choice. A binary, installable package like .deb is therefor no option.
.jib
.deb
These .jib contain metadata and installable code quite analogous to the .deb packages we know, except that the metadata is also used to compile (for the lack of a better term so far) the code on the user side.
compile
The name of a .jib file is determined as follows:
<prefix>-<package-name>-<version>-<authority>.<extension>
In praxis, this will produce a name along these lines:
p5-Foo-Bar-1.1-cpan+kane.jib
The Internal layout is as follows:
- control.tgz * contains the data in the _jib directory - data.tgz * contains the following directories the other directories. This may be limited in the future, by say, a manifest.skip like functionality, or by dictating a list of directories/ files that will be included
There is room to ship more files alongside the 2 above mentioned archives. This allows us to ship an extra md5sum, version, signature, anything.
- Define no more than needed to get started for now - Allow for future extensions - Use YAML as metadata format as it's portable and available standard in perl6
- Prefix Package prefix category (p5) - Name Perl module name (Foo-Bar) - Version Perl module version (1.2.3) - Authority From S11 (cpan+KANE) - Package Full package name (p5-Foo-Bar-1.2.3-cpan+kane) - Description Description of function (This is what it does) - Author CPAN author id (KANE) - Depends Packages it depends on[1][2](p5-Foo) - Provides Packages this one provides (p5-Foo-Bar, p5-Foo-Bar-cpan+kane)
As the <Prefix>-<Name>-<Version>-<Authority> combination make up the <Package> name, arguably, we can leave the former out. The upside is to make sure all fields contain unique information. The downside is that 3rd party parsers will need to understand the Package syntax.
Package
Again, arguably, the Author and Authority fields overlap, and Authority can be made to hold both cases.
Author
Authority
[1] This is packages, *not* modules. If we need a module -> package mapping, this needs to be done when extracting the data from the compiler, and queried against the available packages cache. [2] See the section on L<Dependencies>
- Build-Depends Packages needed to build this package - Suggests Packages suggested by this package - Recommends Packages recommended by this package - Enhances Packages that are enhanced by this package - Conflicts Packages this one conflicts with - Replaces Packages this one replaces - Tags Arbitrary metadata about the package, like flickr and debtags - Contains List of modules (and scripts?) contained in the package [3] Steal more tags from debian policy
Dependency notation allows you to express the following concepts:
Specifies alternatives
Specifies cumulative requirements
Specifies a criteria for the version requirement
This allows nesting of the above expressions
a, b # a AND b [a, b] # a OR b { a => "> 2" } # a greater than 2 { a => 1 } # shorthand for a greater or equal to 1 \[ ... ] # grouping
a, [b,c] # a AND (b OR c) { a => 1 }, { a => '< 2' } # a greater or equal to 1 AND smaller than 2 [a, \[ b, c ] ] # a OR (b AND c) [1] [1] This is possibly not portable to other languages. Options seem thin as we don't have some /other/ grouping mechanism than [ ], { } and \[ ]; ( ) gets flattened and \( ) == [ ]. We could abuse { } to create { OR => [ ] } and { AND => [ ] } groups, but it would not read very intuitively. It would also mean that the version requirements would have to be in the package naming, ie. 'a > 2' rather than a => '> 2'
# a, b -- AND - a - b # [a, b] -- OR - - a - b # { a => "> 2" } -- VERSIONED a: > 2 # { a => 1 } -- VERSIONED a: 1 # \[ ... ] -- GROUPING - !perl/ref: =: - ...
To install Perl6::Doc, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Perl6::Doc
CPAN shell
perl -MCPAN -e shell install Perl6::Doc
For more information on module installation, please visit the detailed CPAN module installation guide.