nosh-kbd-shims-1.35.tgz
(resizecons, clear_console, and chvt shims for compatibility with the old Linux kbd package)

These install the toolsets under /usr/local.
However, to avert a problem that otherwise makes systems unbootable, they also install a handful of binaries in /bin:
/bin/nosh,
/bin/exec,
/bin/cyclog,
/bin/system-manager, and
/bin/system-control.

non-socket services such as cron, atd, anacron, qmail-send, and exim4-queue; and

socket services such as sshd, qmail-smtp-submission, and exim4-smtp-relay.

Important notes:

This is an extensive service bundle collection.
There are a lot of service bundles here, including services that conflict (e.g. qmail-smtp-relay and exim4-smtp-relay) and services that you probably will not have (e.g. rabbitmq-server, mongodb, postgresql, openvpn@service, and swift@container).

Installing the package will automatically enable only a few basic services and targets.
To set your local preferences in this regard, you can use systemd-style preset information in /etc/systemd/system-preset or in /etc/system-control/presets.
So, for example, to have exim4-smtp-relay automatically enabled, include enable exim4-smtp-relay.socket in your preset configuration files.

Installation will not actually start any services.
Deinstallation does not disable or stop services.
Installation and uninstallation of other "-run" packages, reliant upon this one, does that.

In an ideal world, the world would ship nosh bundles with its softwares itself, of course. ☺

-run packages

The "-run" family of packages require the service bundle collection.
They employ services in it; which are not started or enabled unless the packages are installed; and which are stopped, disabled, and unloaded from the service manager when the packages are uninstalled.

Virtual terminal services

The old-style kernel virtual terminal system auto-starts a ttylogin@ttyCN service on each kernel virtual terminal at startup, as configured by /etc/ttys.

The new-style application-mode virtual terminal auto-starts a console-fb-realizer@head0 service; the "realizer" service that realizes the multiplex VTs via the (head #0) framebuffer and input event devices.
This connects to the user-mode virtual terminal that is supplied by console-multiplexor@head0; which in turn multiplexes the user-mode virtual terminals generated by the terminal-emulator@vc0, terminal-emulator@vc1, and terminal-emulator@vc2 services; whose emulated virtual terminals in their turn are employed by the ttylogin@vc0-tty, ttylogin@vc1-tty, and ttylogin@vc2-tty services.
The realizer service tells the kernel to disable its built-in terminal emulator program for the duration.

These systems conflict.
The head #0 framebuffer and input event device are used by the kernel's virtual terminal emulator.
One cannot (without a massive mess of overlapped output and input going to two separate places) realize application-mode virtual terminals onto head #0 whilst simultaneously realizing kernel virtual terminals on the same hardware.
So you must only install one of these packages at any one time.
The BSD package manager does not provide an easy means of enforcing this, unfortunately.

Running nosh service management under OpenBSD rc

This installs various rc.d scripts for running allowing one to use the nosh service management under OpenBSD rc.

It also disables the nosh sysinit standard target, on the basis that rc handles what that target otherwise handles on a nosh-system-managed system.
Thus, installing this package will break a nosh-system-managed system.

OpenBSD Limitations

OpenBSD has several limitations that severely impact nosh.

OpenBSD lacks nmount().system-manager uses the filesystem-neutral API nmount() for mounting the "API" filesystems such as /dev at system bootstrap.
As such, a fully-nosh-managed system, where system-manager is process #1 with complete system management available, is not yet possible.

OpenBSD does not have POSIX realtime signals.
The system-manager and acompanying system-control require the use of 10 realtime signals, including for signalling state changes for halt and poweroff amongst other things.
As such, a fully-nosh-managed system, where system-manager is process #1 with complete system management available, is not possible.

OpenBSD does not have the dynamic pseudo-terminal allocation system introduced in the 1990s.
On OpenBSD, pseudo-terminal master and slave devices are still statically named in /dev/, 1980s-style.
nosh terminal management was designed for systems that implemented the "new" dynamically-naming pseudo-terminal allocation system that arrived in the 1990s, and that can be found in FreeBSD, TrueOS, and Linux.
It may or may not work with the old 1980s system.

OpenBSD lacks fexecve().
nosh service management and chain loading uses file-descriptor-relative versions of many POSIX APIs whereever possible.
It does this in order to avoid well-known security holes where paths are resolved twice or more and attackers can slip in rename()s or links in between steps.
OpenBSD lacks some of them, such as this one.
On OpenBSD, the toolset has to rely upon execve() and pathnames.

OpenBSD does not have pkgng.
It has its predecessor.
pkgng has an easy-to-manage system of running pre-/post- installation/deinstallation scripts.
Its predecessor has a less easy to set up system.
The nosh package's build system is geared towards the pre/post-install/deinstall paradigm, because that's what package management on Debian Linux, FreeBSD, and TrueOS provide.

Also note that the framebuffer realizer for console virtual terminals has yet to be tested.