[Ref: Porter’s Handbook | mk.conf(5) | bsd.port.mk(5) | ports(5) ]
Table of Contents
We are free to compile, and install the programs directly from source.
I like to cause more damage, presumably with good intentions. I like the ports collection, and some of the ‘custom’ compilations I want are minor tweaks on the existing port, and I really want to keep the other advantages from ports (such as binary packages that I can install on other machines, or the appropriate configuration so I can readily compile on another architecture.)
These notes are to remind me of some of the things I always forget when updating ports, even when they are well documented in the above project documentation links.
[Ref: pkg_add(5) ]
One dilemma with our ports collection, are multiple system installs at remote locations over a slow/small pipe. If we knew what we were doing, we’d ship the packages across the link as a batch, but often enough we get called to install systems at short notice.
To help with building multiple systems, we use pkg_add(5)’s ability to cache/keep a local copy of the package.
Pre-cached packages are usually made available on our LAN from another machine, and we can cache packages downloaded during the pkg_add process using the environment variable PKG_CACHE.
mkdir -p /var/pkg/cache
export PKG_CACHE=/var/pkg/cache
export PKG_PATH=$PKG_CACHE/:non-local/package/repository/
echo "export PKG_CACHE=/var/db/cache:non-local/package/repository/" >> ~/.profile
[Ref: FAQ15]
Our production environment requires verifiable sources for all installation binaries (which in this case includes software packages additional to the operating system) With OpenBSD release 5.5, the project distributes signed packages, and by default the package installation process expects signed packages.
If we are required to have an additional level of checks, i.e. we have to build and sign our own software packages, due to some compliance requirement, then the updated FAQ provides all the details for setting up your own/internal signing/validation infrastructure.
#&91;Ref: signify(1)]
OpenBSD 5.5 introduced signify(1) a new tool for now used for signify package binaries. The first advantage is that OpenBSD packages are now cryptographically signed by the people building releases.
Another advantage is the tool is relatively simple to use.
# signify -G -n -s /etc/signify/myorg-pkg.sec -p /etc/signify/myorg-pkg.pub
File extract: /etc/mk.conf (OpenBSD 5.5 and later)
SIGNING_PARAMETERS=-s signify -s /etc/signify/myorg-pkg.sec
To use your signed packages, ensure the public signing key is on the new host (/etc/signify/myorg-pkg.pub)
[Ref: bsd.port.mk(5) ]
So, why do we put our ‘customisations’ in /usr/ports/mystuff ?
No one ever seems to explain why everyone is doing it? Two configurations that help explain ‘mystuff’ are PORTSDIR and PORTSDIR_PATH as described in the manpage.
manpage extract: bsd.port.mk(5)
PORTSDIR Root of the ports tree (default: /usr/ports).
PORTSDIR_PATH
Path used by dependencies and bsd.port.subdir.mk to look up
package specifications. Defaults to
${PORTSDIR}:${PORTSDIR}/mystuff.
...
${PORTSDIR}:${PORTSDIR}/mystuff
Extra directory used to store local ports before committing
them. All depend targets will normally look there after the
normal lookup fails. See PORTSDIR_PATH.
Refer to https://github.com/jasperla/openbsd-wip for sample usage.
So, when you are in your custom port and you type in ‘make package’ the ${PORTSDIR_PATH} is traversed to solve dependencies of your package. Pathing is significant, so if you need ‘mystuff’ traversed first, then make sure you make the appropriate changes, such as the below:
File extract: /etc/mk.conf
PORTSDIR_PATH=$PORTSDIR/mystuff:$PORTSDIR
[Ref: BSD Now Tutorial]
When you can dedicate a machine for building source, you can make global changes to assist in successful port builds.
File extract:
default:\ ... :datasize-max=4G:\ :datasize-cur=4G:\ :maxproc-max=512:\ :maxproc-cur=256:\ ... :tc=default: staf:\ :datasize-cur=4G:\ ... :maxproc-cur=256:\ ... :tc=default: