# Packages and ports

Here are some tips for people wanting to make packages, or to add nosh service bundles to existing packages or ports.

## Converting systemd units

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 yourself. Usually this is not done by hardwired rules files in your package, but by creating the necessary directories and files in your package's (post-)install script.

  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; and symbolically link the IPv6 aliases to the IPv4 directories.

- 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.

## The problem of `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.