Plasma GitLab Archive
Projects Blog Knowledge

GODI Project:
Home 
Highlights 
Screenshots 
Get GODI 
Docs 
Mailing List 
Resources 
Packages 
Workgroups 
OASIS 
Why Ocaml? 
GODI is discontinued. This is the archived content of the former site godi.camlcity.org.
======================================================================
Reference for the GODI package database
======================================================================

$Id$

The package database is the directory $GODI_DBDIR, which is usually
$LOCALBASE/db. For every installed package a new subdirectory is
created containing the meta data. The name of the subdirectory is the
full package name (with version number of package revision), e.g. for
the package foo-3.4godi15 the directory $GODI_DBDIR/foo-3.4godi15 is
used.

The case that several versions of the same package are concurrently
installed is currently out of this specification. (Don't do this for
now.)

The meta data directory may contain the following files:

- +CONTENTS: This file is required. It is the transformed PLIST
  describing the files of the package.
- +COMMENT: This file is required. This is the one-line comment.
- +DESC: This file is required. This is the multi-line description of
  the package.
- +MAINTAINER: This is the one-line GODI maintainer.
- +DISPLAY: A multi-line text to be displayed whenever a binary
  package is installed.
- +BUILD_VERSION: XXX
- +BUILD_INFO: XXX
- +PRESERVE: If existing, the package cannot be deleted (unless GODI
  is forced to do so).
- +REQUIRE: This is the requirements script.
- +INSTALL: This is the script with pre- and post-installation actions.
- +DEINSTALL: This is the script with pre- and post-deinstallation actions.
- +REQUIRED_BY: This file list other packages requiring this
  package. (Speeds certain queries up.)

----------------------------------------------------------------------
+CONTENTS:
----------------------------------------------------------------------

Format is similar to PLIST (see plist-ref.txt). However, only the
following directives can be used:

@name <name>
  Declares the full name of the package, including version number
  and package revision.

@cwd <path>
  At least one @cwd directive is required. The meaning of the first
  @cwd is that it declares the installation prefix of the package.
  The first @cwd must currently be an absolute path because packages
  are non-relocatable. In the future, we might add the convention
  that "@cwd ." indicates a relocatable package.

  It is allowed to have more than one @cwd directive. These must use
  relative paths, and change the current installation directory
  relative to the previous one. It is now allowed to change outside of
  the directory hierarchy denoted by the first @cwd. The current
  installation directory is used to refer to files, @rmdir, @exec and
  @unexec. For example:

  @name foo-3.4
  @cwd /godi
  bin/sample1
  @cwd bin
  sample2
  @cwd ..
  lib/foo.a

  This +CONTENTS file refers to the files "/godi/bin/sample1",
  "/godi/bin/sample2" and "/godi/lib/foo.a".

@pkgdep <dependency>
  A run-time dependency.

@blddep <dependency>
  A build dependency (this is just a comment).

@pkgcfl <dependency>
  A run-time conflict.

@display +DISPLAY
  The contents of the file +DISPLAY are shown when the binary package
  is installed.

@dirrm <path>
  Ignored.

@exec <cmd>
  The command <cmd> is executed with /bin/sh at installation time.
  <cmd> may include some %-placeholders (XXX). %D is replaced by the
  absolute path to the current installation directory.

@unexec <cmd>
  The command <cmd> is executed with /bin/sh at deinstallation time.
  <cmd> may include some %-placeholders (XXX). %D is replaced by the
  absolute path to the current installation directory.

@ignore
  Ignore the following directive.

@option extract-in-place
  Indicates that the package should be extracted in-place instead of
  first extracting it to a staging directory and then moving the files
  to their final locations.

  This is not (yet) implemented; the option is ignored.

@option preserve
  Indicates that the following files may replace existing files owned
  by other packages. The existing files are not overwritten, but are
  moved away to a safe place. When this package is deinstalled, the
  files are moved back.

  Effectively, one can make patch packages with this feature. The
  patch package should be dependent on the package it patches, and
  enable this option.

@comment <text>
  An arbitrary comment.

@comment MD5:<hex>
  This is a checksum for the immediately preceding file.

This web site is published by Informatikbüro Gerd Stolpmann
Powered by Caml