The sp-install program

sp-install /package/admin/foo-2.0 [...]
sp-install foo-2.0.tar [...]
sp-install [...]

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, sp-install will:

You can alter this behavior by setting these environment variables:

If you specify a tarball, not a directory, then sp-install will store temporary files in $TMPDIR (defaulting to /tmp).

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, except for package/own and 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 sp-install's automatic 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 conf-compile/. (For an example, take a look at how runwhen depends on skalibs; runwhen's package/INSTALL and conf-compile/defaults/depend_skalibs files explain how it works.) 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 applying $SP_ROOT multiple times to the same configuration path.