Package Specification 1.0 Working draft
Rolf Veen, 12 Nov 2004. License TBD.
The package format described in this document is based the following principles:
-  Each (installed) package is a directory or directory tree.
-  System wide installation is acomplished by creating symbolic links into the system's directories.
- [3A] Each package is responsible for providing an interface layer to the common installation, configuration and initialization tools.
- [3B] The base system is responsible for providing a common interface layer that "abstracts platform/distribution specifics
that has to be used in pre- and post-install scripts (how to start and stop daemons, how to register a cron job,
how to get logs automatically managed, etc.)" (quoted from Bud Bruegger, "The Universal Source Package").
-  There is a top level package directory defined by variable $PACKAGES. All packages reside below it.
$PACKAGES defaults to /pkg for root, and $HOME/pkg for normal users.
-  There is a top level data directory /data, from where the system and package data is accesible. There is also a top level /doc
directory with access to documentation.
-  The package name corresponds to the directory name below $PACKAGES. It can include version numbering. The namespace is flat,
i.e., packages are not classified in categories.
-  Subpackages are allowed: a package can be a hierarchy of packages.
- [8A] Each binary package has a descriptor in OGDL format, with the file name pkg.g.
This file is the connection between the package and the package manager. Per definition, each directory with a pkg.g file in it
is a package or subpackage.
- [8A] Each source package has a descriptor also in OGDL format, with the file name src.g.
-  Package files are regular archive files, in formats such as tar+gzip or tar+bzip2. They are regular in the sense that they can
be unpacked just like any other tar.gz or tar.bz2 file, with standard commands or utilities.
-  Package files may contain one or more packages; each package is a directory tree in this archive. The archive file is setup
so as to create one directory
per package, allways relative to the current directory. Unpacking outside the package's directory and the use of absolute paths are not allowed.
-  A binary package can be defined as a bundle of executable code, data and documentation ready to be installed on a target system.
A source package is a bundle of code, data and documentation that needs still to be build before it can be used.
-  The file system may be the database.
-  Packages as defined here are not particular to any system directory layout. It is the task of the package manager to adapt
the package to the system.
-  Each package can contain from zero to more that one services. A service can be performed by more that one package, but in
any case each service is contained in a package. Services in a package can be considered subpackages.
2. Life cycle
- Get the files from URLs found in a descriptor. This includes external patches.
- Place the files in a local repository. Files should not overwrite
any previous version or files from other packages.
- Files can also come from a CVS or similar repository .
- Unpack the files corresponding to a package release into a working directory. This includes
patches (but we should be able to select which ones).
- Cope with non-standard procedures, such as java or binary packages (no build).
- Dependencies and the ./configure script.
- Different needs: cross-compiling, merge into system, make chroot system, /packages versus /.
- Preserve configuration information
- Some packages can be installed more than once (slotted).
- Virtual packages (webserver, mailserver ...).
- Package information database formats.
- Init and cron tasks
When installing a package there are some defined phases:
- 1. The file is unpacked in a temporory directory.
- 2. A sanity check is performed.
- 3. The install-pre command is executed, if it exists.
- 4. The package is moved to its definitive location.
- 5. The install command is executed, if present and it is a system wide installation.
Several versions of the same package can be installed on one system, but only one is the default, the one that
has unversioned system-wide names.
Dependencies between source packages can be required or optional. The optional dependecies may need to be controlled
throught configuration switches or they may be detected at build time. Dependencies between binary packages can also
be required or optional, but should in general not need any runtime switch or adjustment.
The package descriptor lists only the runtime dependencies, in the form of package names and optionally a version
number. It is responsibility of the package manager to solve any required dependencies.
2.3. Package archive names
Binary packages: pkg-version.arch.ext
Source packages: pkg-version.ext | pkg-version.src.ext
3. The (binary) package descriptor (pkg.g)
The GNU family of grep utilities may be the "fastest grep in the west".
GNU grep is based on a fast lazy-state deterministic matcher (about
twice as fast as stock Unix egrep) hybridized with a Boyer-Moore-Gosper
search for a fixed string that eliminates impossible text from being
considered by the full regexp matcher without necessarily having to
look at every character. The result is typically many times faster
than Unix grep or egrep. (Regular expressions containing backreferencing
will run more slowly, however.)
cd work || exit -1
rm -rf *
cd $package-$version || exit -1
export CPPFLAGS=-Dre_max_failures=re_max_failures2 &&
./configure --prefix=$PWD/dist --disable-nls &&
unset CPPFLAGS &&
make LDFLAGS=-static &&
# remove busybox link
rm -f $destdir/bin/grep
cd work/$package-$version || exit -1
cp dist/bin/* $desdir/bin/
4. Package layout
Package hierarchy (an example)
| |-- info
| |-- man
| `-- web