You might want to use one machine for builds and another (perhaps a VM or a local zone) to test the resulting binary code. One way to achieve this is to fire up an IPS package depot server instance to publish your freshly-built repository. Then you would configure the target machine to use this new publisher and update its boot environment in standard ways. This is detailed in Installing built illumos packages into BEs on a remote host and non-onu updates.
You can run a package depot server instance from command-line, usually to install a single build, or you can set it up as an SMF service instance maintained by the build host's OS as any other service (including
svcadm disable and
svcadm restart actions). Both methods are described below.
Note that the build process and the package repository publishing service can be executed in a local zone, or perhaps in separate OE's (i.e. via shared storage or by publishing built packages from the build host to a remote package depot); however this is a rather advanced topic and not explored below, to keep it short. See http://wiki.openindiana.org/oi/Building+in+zones for example setup of a zone for building OpenIndiana userland software; similar setup can be done for illumos kernel builds.
Running a package depot can be done as a one-shot operation like this in a terminal session:
$ sudo /usr/lib/pkg.depotd -d /code/illumos-gate/packages/i386/nightly/repo.redist/ -p 8151 \ --proxy-base http://"`hostname`.`domainname`":8151/on-nightly
8151is an arbitrarily chosen available port number (8 for HTTP, 151 for oi_151-based build). You might want to pick an available port number under 1024 to ensure that no unprivileged userland program grabs it occasionally for its communications, and use RBAC privileges to allow this service to use the privileged port.
pkg.depotdversions might also require that you add this option (not needed as of oi_151a based server):
You can also create an SMF instance to run this server (here we create a dedicated instance which should not be overwritten by OS upgrades; you can also override the
default instance's settings, but such customization may be lost during upgrades or migrations):
sudo svccfg -s svc:/application/pkg/server add on-nightly sudo svccfg -s svc:/application/pkg/server:on-nightly addpg pkg application sudo svccfg -s svc:/application/pkg/server:on-nightly setprop pkg/inst_root = \ astring: "/code/illumos-gate/packages/i386/nightly/repo.redist" sudo svccfg -s svc:/application/pkg/server:on-nightly setprop pkg/port = count: 8151 sudo svccfg -s svc:/application/pkg/server:on-nightly setprop pkg/readonly = boolean: true sudo svccfg -s svc:/application/pkg/server:on-nightly setprop pkg/proxy_base = \ astring: "http://`hostname`.`domainname`:8151/on-nightly"
NOTE: Like above, the last setting of
proxy_base URL is optional.
Enable the SMF server instance:
$ sudo svcadm refresh on-nightly && \ sudo svcadm enable on-nightly
Optionally, monitor its SMF log file for errors, etc.:
$ sudo /usr/gnu/bin/tail -F /var/svc/log/*on-nightly* &
If you rebuild your
on-nightly repository, it might make sense to recycle the package depot server, just in case, like this:
$ time ./nightly.sh -i illumos.sh && \ sudo svcadm restart on-nightly && \ svcs -p on-nightly
For more information about
pkg.depotd server, see the man pages: