PKGURL vs. PKGSRVR discussion for kayak-kernel.
Build Instructions #See also the illumos developer's guide if you are interested in contributing to illumos. OmniOS is a near-optimal platform for developing against illumos-gate or our own downstream illumos-omnios.
# git clone https://github.com/omniti-labs/omnios-build
# git clone firstname.lastname@example.org:~omnios/core/omnios-build
To build a single package, including illumos as well as the third-party packages:
# cd omnios-build/build # ./buildctl list # ./buildctl build <pkgname>
To a first approximation, the buildctl script goes into one of the build/* directories and run ./build.sh. Every package is generated by a "simple" bash script of the same name. The job of these build scripts is to download, compile, mock-install, assemble packages and finally publish packages into the repo specified in lib/site.sh.
If you're only interested in re-rolling the illumos packages:
# cd illumos/ # ./build.sh
Note that the illumos build script uses a different TMPDIR than most of the other build scripts, and by default it is not under /tmp. It defaults to "/code" which is typically on its own ZFS dataset, possibly with child datasets for different workspaces. If you build illumos separately, the illumos build.sh will honor the PREBUILT_ILLUMOS variable, and wait for that nightly to finish before merging the debug and non-debug packages.
Because of the annoyance with a hardwired ZFS dataset, as well as being more friendly to illumos developers who often build illumos-omnios before building the rest of the system, buildctl has been enhanced. See the dedicated buildctl page for more.
How to roll your own software #One of the advantages of IPS is that it is build system agnostic. However you wish to build your software, you can get it packaged into IPS.
The OmniOS build scripts are on Github. If you clone the "template" branch, you will have a good starting point for rolling your own software distributions. You simply need to setup a repo and alter the lib/site.sh file in order to specify your publisher name and repository location.
A working example of this is how OmniTI's managed services group rolls its packages, which is found in the omniti-ms branch.
Package Notes #Certain packages have idiosyncrasies that are documented below.
git #Git documentation is written in AsciiDoc, which requires an enormous number of dependencies, adding support overhead and bloat for little benefit. We instead get the manpage tarball that is distributed along with the source tarball from http://code.google.com/p/git-core/downloads/list and add them to the pkg proto area before packaging.
The build script takes care of extracting them, but it means that both the main source and the manpages archives should be fetched to mirrors.omniti.com (or your own mirror) before building.
kayak #Kayak builds have two components: kayak, and kayak-kernel. kayak-kernel requires privilege (either run as root, with sudo(1), or with appropriate finer-grained privileges). To this end, the buildctl script has certain variables that can help assist with worry-free Kayak builds. Otherwise, chdir()-ing directly into the kayak-kernel/ directory and uttering "sudo ./build.sh" may work as well.
Also mentioned on the buildctl page: kayak-kernel pulls its bits from PKGURL if specified, or PKGSRVR if PKGURL is not specified.
illumos #Already mentioned above is the TMPDIR change vs. every other package. Because illumos-omnios is the largest set of source, and because many OmniOS builders make changes to illumos-omnios, the PREBUILT_ILLUMOS variable can be exploited to install an already-built-and-packaged illumos-omnios. See the buildctl page for more details.
Creating Installation Media #See ReleaseMedia
Keeping Up With The Flow #See the Maintainers page for how we stay in sync with illumos-gate.
See the OmniOS-on-demand page for how the bloody repo is built every time illumos-omnios or omnios-build changes.