Table of Contents
The Python Package Manager
A pbuild(5)
script is written
in shell code and consists of a number of definitions for specially named
functions that are called actions. It is given a preprocessed environment
with useful shell functions and variables. Its purpose is to somehow emulate
the steps a user would normally do to install a certain package. pbuild
scripts are not needed for common distutils-compliant packages, that can
be installed via setup.py.
The following is a short example to give
you an idea on what pbuild scripts are actually intended to be used for.
It is the pbuild script for the Python Imaging Library. It comes with a
C extension that has to be built before it is installed executing the setup.py
distutils script.
# PIL - Python Imaging Library 1.1.4
#
pre_build() {
(cd libImaging && ./configure)
error $? "configuring C extension failed"
}
build() {
(cd libImaging && make)
error $? "making C extension failed"
$PYTHON setup.py build
}
It overrides two actions: pre_build and build. The install action needs
not be overridden because the default is ok.
There are
some variables you should/must define at the top of a pbuild script:
- PACKAGE
PACKAGE="foobar"
Define which package this pbuild script provides. The default is the name
of the pbuild script with the file extension stripped.
- VERSION
VERSION=">=1.0 <2.0"
Set which versions of the package can be built and installed with this
pbuild script.
- PATTERN
PATTERN="egenix-mx-base"
PATTERN="qscintilla-(.+?)-x11-gpl"
PATTERN="foobar foobaz quux"
Specify one or more regular expressions which a source package filename
must match in order to be used as a source. Matching is done case-insensitive.
The default is the value of PACKAGE.
- DEPEND
DEPEND=" >=sip-3.6
>=qscintilla-1.52"
If the package depends on other packages, you may state this using this
variable. You can use all kinds of operators ("<", "<=", "=", "!=", ">", ">=").
If a package does not depend on a particular version of another package,
the package name on its own will do.
- inherit pbuild
-
inherit
sip
Include another pbuild into the current one, which makes it possible to
reuse the same functions across different pbuild scripts. IMPORTANT: put
this statement BEFORE the package definitions or these could get overwritten!
- testver version1 operator version2
-
testver 1.3 ’>’ 1.2
Compare two version numbers using the operator.
- info message
-
info "this
may take a while"
Display an informational message. In contrast to all other output of a running
pbuild script, an info message is displayed independently of the --verbose
switch.
- die message
-
make || die "make failed"
Terminate pbuild script with an error message.
- pre_unpack
- Perform actions that must take place before anything is done, e.g. warn the
user of potential risks when installing the package.
- post_unpack
- Perform
all actions that modify the source after it has been unpacked, e.g. apply
patches, run sed(1)
etc. The unpacking itself cannot be customized, it is
done internally by pmgr.
- check_depend
- Test for dependencies and prerequisites.
It is encouraged to specify dependencies with the DEPEND package definition.
check_depend should be used only if the DEPEND definition does not work
for you due to some reason.
- pre_build
- Perform actions that have to be done
before the source is built, e.g. configure C sources.
- build
- Build the sources,
the default action executes a possible setup.py distutils script.
- pre_install
- Perform actions that must take place before the package is installed to
the sandbox.
- install
- Install the built sources to the sandbox. The default
function executes a possible setup.py distutils script.
- post_install
- Perform
actions immediately after the package has been installed.
- help_message
- Display a list with useful information on the package, e.g. configuration
options.
- PYTHON
- The python interpreter/installation that the
package will be installed for, see --python option.
- PBUILD
- The path to the
pbuild script itself.
- FILESDIR
- The path to a directory in the pbuilds tree,
where additional files like patches etc. can be stored.
- S
- The working directory,
it is the initial directory for every execution.
- D
- The sandbox root directory.
Prefix every path with $D to avoid sandbox violation.
- COMMAND
- The command
currently executing.
- P
- The fully-qualified package name, e.g. imaging-1.1.4.
- PN
- Only the package name.
- PV
- Only the package version.
Use the following paths
for installation, if you need to install directly. All these paths reside
in the sandbox and are safe for use.
- PY_PREFIX
- The prefix of the python
installation, e.g. /usr.
- PY_EXECPREFIX
- The exec prefix of the python installation.
- PY_INCLUDE
- The directory of the python header files.
- PY_LIBRARY
- The directory
of the python libraries/modules.
- PY_SITEPKG
- The directory for python’s site
specific packages. Install your modules here.
- PY_SCRIPTS
- The directory for
python scripts.
- PY_PMGRPKG
- A pmgr specific directory where arbitrary files
can be stored that are no python modules/packages/extensions but are needed
by other packages, like header files and libraries.
NEVER use the following
paths for installation, you may just use them for reading, e.g. inclusion
of python header files.
- SYS_PY_PREFIX
- The prefix of the python installation,
e.g. /usr.
- SYS_PY_EXECPREFIX
- The exec prefix of the python installation.
- SYS_PY_INCLUDE
- The directory of the python header files.
- SYS_PY_LIBRARY
- The directory of
the python libraries.
- SYS_PY_SITEPKG
- The directory for python’s site specific
packages.
- SYS_PY_SCRIPTS
- The directory for python scripts.
- SYS_PY_PMGRPKG
- A pmgr specific directory where arbitrary files can be stored that are
no python modules/packages/extensions.
pbuild(1)
, pmgr(1)
http://pmgr.sourceforge.net/
Lars Gustaebel (gustaebel@users.sourceforge.net)
Table of Contents