Here are some tips for people wanting to make packages, or to add nosh service bundles to existing packages or ports.
One approach to adding a service bundle to an existing package or port is to convert an existing systemd service or socket unit that comes with the bundle as part of its build process.
There are several things that the convert-systemd-units command does not do:
Conversion will not create any environment directories, as used by envdir commands.
If your package is intended to also install the environment directory, then you need to explicitly create it in your package's staging area yourself.
The conventional location for an environment directory is service/env within the service bundle.
Conversion will not create any rules directories, as used by ucspi-socket-rules-check commands.
If your package is intended to also install the rules directories, then you need to explicitly create them in your package's staging area yourself.
The conventional locations for the rules directories are service/ip4 and service/ip6 within the service bundle.
For administrator convenience, you may want to supply at least the service/ip4/10.0.0.0_8, service/ip4/127.0.0.0_8, service/ip4/192.168.0.0_16, service/ip6/::1_128, service/ip6/::ffff:10.0.0.0_104, service/ip6/::ffff:127.0.0.0_104, and service/ip6/::ffff:192.168.0.0_112 directories in your package as well.
Conventionally, logging services contain a main symbolic link in the root of the service bundle that points to the actual log directory.
This symbolic link is not actually necessary to the operation of the service, but as a convenience to administrators wyou may like to supply it in your package, by explicitly creating it in your package's staging area.
down files
When it comes to making pre-packaged service bundles, down files are a problem in two ways:
down files and wants/ or conflicts/ symbolic links (from a bootstrap target) must not be created by installation/upgrade.
To do so would be to forcibly mark enabled services as disabled, or vice versa, every time that a package is installed, reinstalled, or upgraded.
Do not include down files or wants/ or conflicts/ symbolic links from a bootstrap target (i.e. the symbolic links that are automatically created/removed as the inverses of the wanted-by/ or stopped-by/ symbolic links when enabling/disabling services) in the service bundle images in your packages.
The mechanisms have opposite sense defaults when the files are not packaged.
If a down file does not exist, then a service is considered enabled by service-dt-scanner.
If a wants/ or conflicts/ symbolic link does not exist pointing to it, then a service is disabled as far as system-control is concerned.
Unfortunately, this is exactly the scenario that initially obtains when a packaged service bundle is first installed.
There are two approaches to dealing with this.
One can arrange for the post-installation and post-upgrade scripts for one's package to explicitly preset all services at every install, reinstall, or upgrade; this matching the installing-package-enables-services philosophy of some operating systems.
Or one can arrange for the post-installation and post-upgrade scripts for one's package to attempt to bring the mechanisms back into synch, usually by bringing the down file into synch with the wants/ and conflicts/ symbolic links rather than the converse.