This documentation describes the current state of the package management development system. Idealised behaviours, plans and designs belong elsewhere: TODO make a page for them.
Anatomy of a Package
A normal opkg package
An opkg compatible package is an
ar != tar) archive containing the following files:
- A 'magic' file containing only the string
- A gzipped tar archive containing package metadata and install scripts. This contains the following files:
- Package metadata
- A list of files which should be considered user-modifiable config files.
- Scripts to be executed as part of the (un)install process.
- A gzipped tar archive containing the package payload.
A package in the SOWN SVN
In the SOWN package_build SVN each package its own directory in
That package directory may contain the following files:
- A declaration of the package metadata. Can also declare symlinks, files and config files.
- A list of normal files and configuration files to be included in this package.
- These file paths consider the
data/directory to be the root of the filesystem
- Scripts to be executed as part of the package (un)install process.
Checking out the SVN
svn co svn+ssh://sown-auth/srv/subversion/package_build
Modifying a package
Edit them in the
Add/Remove files by adding their filenames to
The package builder will try to do sensible things with symlinks listed in
files.txt, but if it does not work, they can be added in
init.php by php calls on the package object.
Building a package
Most of the time the Makefile will be sufficient for your needs:
However if you wish to build a package individually:
The -v option may be added for extra spam:
./build.php -v [package_name]
The package builder attempts to uses the svn revision to ensure that package version numbers always increase. Please commit all changes before building packages for release.
Deploying a package
Currently the only means of deploying a package to a node is to copy it to the node's filesystem (e.g. scp) and install it manually:
opkg install [filename]
Resolving non-installed dependancies will fail if the node has not successfully run
opkg update since it booted.
When working with a vm, there are useful commands for this in the
Running a VM
The magical incantations are listed in the
No special network configuration is needed for the userspace natting vm incantations to work, however with userspace natting ICMP is broken, so all server reachability checks will fail because they rely on Ping.
Currently non-userspace-natting is only configured on Leth's desktop.