sp-install /package/admin/foo-2.0 [...] sp-install foo-2.0.tar [...] sp-install http://example.org/foo/foo-2.0.tar [...]
sp-install installs one or more packages. Each argument names a
a package directory, a tarball (possibly compressed with gzip or bzip2) or a
URL. By default,
/package, if a URL or tarball was given, or run
sp-unpackon the package directory name otherwise;
compile/subdirectory, if it exists, to ensure a clean build;
package/compilescript to build the package;
package/ownscript if it exists, so the package can set any special ownership or setuid/setgid bits that it needs;
package/checkscript if it exists, to check that the package is working correctly;
sp-versionto set the current-version symlink;
$SP_REPLACE_LINKSset to "
n" by default if the package name is under "
host/") to install symlinks in
/usr/local/bin, pointing to the files in the package's
command/subdirectory, if it exists; and
package/runscript if it exists, to make the package's services available to the system.
You can alter this behavior by setting these environment variables:
$SP_ROOT: unpack the tarball in
$SP_ROOT/package(if the given path is a regular file) and install the command symlinks in
$SP_ROOT/usr/local/bin. This is useful mainly for non-root users.
$SP_HOOK: this specifies a program to be run at various points during the installation. It is invoked with its first argument indicating what point it is being invoked from, and with these environment variables indicating the package being installed:
$SP_VERSION. If the hook program exits with status 99, the rest of the installation of that package is skipped.
$SP_HOOKis run with these arguments during installation:
y; see below),
$SP_STOP_AFTER=unpack: stop after unpacking the tarball, before configuring.
SP_STOP_AFTERis deprecated in favor of
sp-installto automatically adjust the compile-time configuration to use the augmented path for this package and dependencies, in cases where
sp-installrecognizes how to express that.
$SP_STOP_AFTER=configure: stop after unpacking and configuring the package, before compiling. This is useful when you want to further change the compile-time configuration before installing.
$SP_CLEAN=n: don't remove the
compile/subdirectory before installing.
$SP_TRUST_INSTALL=y: after unpacking the tarball, simply run
package/installinstead of doing the individual steps explicitly. This overrides all the following variables.
$SP_COMPILE_USER: unpack the tarball and run
package/compileas this user; this is useful only for root and requires one of the admin/daemontools package, Perl, Python, or Guile.
sp-installwill also edit the compile-time configuration to compile as this user, in cases where
sp-installrecognizes how to express that.
$SP_DO_OWN=n: don't run
package/own. This is the default when running as non-root.
$SP_KEEP_COMPILE=y: don't remove the
compile/subdirectory after building the package.
$SP_STOP_AFTER=build: stop after building the package, before updating the current-version symlink. This is useful when you want to test the package before marking it as the current version.
$SP_SKIP_TEST=y: don't run
$SP_IGNORE_TEST_FAIL: if set to "
sp-installwill continue with installation even if the
package/checkscript fails. If set to "
sp-installwill not complete the installation of this package, but it will continue with the installation of other packages given on the command line and exit 0.
$SP_STOP_AFTER=version: stop after updating the current-version symlink, before creating command symlinks. This is useful if some of the command names may conflict with other commands on your system.
$SP_COMPAT=n: don't create command symlinks in
$SP_STOP_AFTER=links: stop after creating command symlinks, before running
package/run. This is useful if you want to manually control integrating the package with your system.
If you specify a tarball, not a directory, then
store temporary files in
$TMPDIR (defaulting to
A note on security: if you run
sp-install as root with
$SP_TRUST_INSTALL=n (the default),
$SP_STOP_AFTER=links or the equivalent with
$SP_HOOK (not the default) and
$SP_COMPILE_USER=somebody (not the default), then
sp-install will not run any code from the package as root,
package/check; those are
the only parts of the package you need to trust, plus sptools itself.
Ideally, there should be some sort of automatic signature verification, but
I'm not sure how it should work.
Here's a useful
$SP_HOOK example. If
you manually add a
package/url_src file to a package that
doesn't supply one of its own, to enable
downloading for upgrades, then this hook will copy that
package/url_src file into the new version.
A note to package authors: please do
not make your package's build system aware of
$SP_ROOT or other sptools-related configuration. Instead, let
your package be reconfigured by editing files in
(For an example, take a look at how runwhen
depends on skalibs;
conf-compile/defaults/depend_skalibs files explain how it
sp-install will edit your configuration files to tell
your package where various things are. This way, the configuration
information that was used to build the package will be recorded in the
filesystem for later reference, and there will be no risk of accidentally
$SP_ROOT multiple times to the same configuration path.