Creating GODI packages with GODIVA

Overview

  1. Obtain the source for the project you are packaging. Make sure it adheres to the packaging policy.
  2. If it does not adhere to the policy, you will have to patch the Makefile(s) to make it adhere. Similarly, you may need to add files to the source tree before it is built.
  3. Create a specification file for the package.
  4. Run godiva on the spec file. You also have to specify the base of the godi installation into which you want to write the package. 
    5. [info] This is GODIVA version 0.9.5.
Usage: godiva [options] spec
  -localbase <dir> specifies a GODI localbase instead of $GODI_LOCALBASE
  -patch <patch>   includes the given patch
  -filesdir <dir>  includes the given hierarchy of files
  -camlsyntax      use the ocaml syntax (devel only)
  -refetch         refetches the distfile instead of using a cached one
  -nosquash        fail if an old package is in the way
  -quiet           do not print informational messages
  -veryquiet       do not print warnings or informational messages
  -version         display version information and exit
  -help            display this help information and exit
  --help           display this help information and exit

The Spec File

Quick Start

Syntax

Some fields are optional. Fields must be given in the order specified here.

Comments should be between (* and *), and they may be nested.

Fields

Package
Version
Revision
Depends/Build-Depends
Sources
Unpacks-to
Bytecode-Target/Opt-Target
Homepage
Maintainer
Options
Docfiles
Description

Package: <category>-<name>
(required)

The name of the package, prefixed by its category and a '-'. For example, the piece of software named "foolib" with category "godi" gets the name "godi-foolib". Current GODI-supported categories are as follows:

  • "base" - ???
  • "godi" - The core O'Caml system (runtime, compilers, development tools), plus libraries. (example: godi-findlib)
  • "conf" - Configuration packages. These are basically used to specify the location of some extra dependency. (example: conf-pcre specifies the location of the system pcre libraries)
  • "apps" - Applications.
Version: <version>
(required)

This must begin with a digit, and may not contain the "-" character.
Revision: <revision>
(required)

This refers to the release of the GODI package, not the version of the software itself. The first time a given piece of software is packaged, it should have revision 0. A newer revision is needed if something significant is added to the GODI package that should urge users to update, e.g. a security patch is applied. This should always be a single integer.
Depends: [<dep> <dep> ...]
(required)
Build-Depends: [<dep> <dep> ...]
(optional)

A <dep> has the following syntax:

<category>-<name> [(<relop> <version>)]

Legal relops include: >, <=, <, >, and ==.

Examples: 

godi-ocaml (> 3.06)
conf-foo
Sources: <url>
(required)

The url at which the source tarball can be found. For example: 

http://www.phauna.org/foolib/foolib-2.0.tar.gz
Unpacks-to: <dir>
(optional)

If the source tarball does not unpack to a directory whose name is not the same as the basename of the tarball, you can specify the name of the directory it unpacks to here.
Bytecode-Target: <target>
(optional)
Opt-Target: <target>
(optional)

The target that is used to make bytecode defaults to all; the target that is used to make optimized code defaults to opt. Here you can specify what targets to use.

Homepage: <url>
(required)

The url of the homepage for the project. For example: 

http://www.phauna.org/foolib/
If there is no homepage (for example, for conf- packages), use 'n/a'.

Maintainer: <name> <email>
(required)

The GODI package maintainer's name and email. The email should be surrounded by angle brackets. For example: 

Owen Gunden <ogunden@phauna.org>
Options: [<opt> <opt> ...]
(optional)

Legal values for <opt> include:

configure If the software requires that a configure script be run before it will compile.
bmake If the software requires BSD-make instead of GNU-make.
opt If the software has a separate target to make native code.
htdoc If the software provides html documentation (not yet implemented)

Docfiles: [<file> <file> ...]
(optional)

These are the names of files which will be copied into the package's doc directory (<godi-base>doc/<category>/<name>). These should be specified relative to the top-level directory of the expanded tarball. Example: 

README, VERSION, doc/README.too, LICENSE

As of version 0.9.6, you can also specify directory names to have the entire directory copied into the package's doc directory.

Description: <short_desc>
<long_desc>
.
(required)

The short description should fit all on one line. The long description must be terminated with a `.' character on a line all by itself.

Patches

Patches should have names like patch-XX-NAME, where XX is a two-letter code, and NAME hints at which file is to be patched. Since the patches will be sorted by name before being applied, the XX code is used to indicate an order in which to apply multiply patches.

For patches that are not in the top-level directory of the target sources, the filename should have a name like patch-XX-PATH-TO-FILE, i.e. convert the slashes to dashes. And the patch header must contain the path to the file, e.g. 

---subdir/Makefile.orig    [...]
+++subdir/Makefile    [...]

Patches can be included with the -patch argument to godiva.

Extra Files

If you need any extra files to be copied into the top-level directory of the expanded tarball just after it is expanded, you must use the -filesdir option to godiva. You may indicate that the file is to be placed in a particular subdirectory of the top-level tarball expansion by placing it in a particular subdirectory of the files directory. For example: 

files/foo/bar.ml
would end up putting the bar.ml directory into the foo subdirectory of the top-level tarball expansion.