Description
Background
qmail services, and by extension notqmail services, are expected to be run under daemontools-style process supervision. While this is not required, the legacy of public opinion on the qmail mailing list and in the netqmail/Life with qmail documentation encourages it.
daemontools-0.76 is distributed in "slashpackage format", a djb-devised source code packaging format with a number of advantages over other packaging conventions. The slashpackage format and its design goals are documented on cr.yp.to.
While "slashpackaging" has not seen widespread adoption, a number of people including myself have taken to porting their software into slashpackage format for easy deployment, installation, and upgrading with package-provided scripts called ./package/compile, ./package/upgrade, and ./package/install (usually ./package/install just calls ./package/compile and ./package/upgrade directly).
What this could mean for notqmail
A slashpackage package has a strict path that it must follow because package names are globally allocated. Underneath, for example, "./mail/notqmail-v.ers.i.on/", are a ./package directory and a ./src directory.
The ./src directory contains the source code for the package. To simulate this structure on a local git repo:
mkdir -p ./mail/notqmail-version/src
chmod +t ./mail
ls -1 | while read f; do git mv $f ./mail/notqmail-version/src/; done
While this is simple enough for a user to do this when building a notqmail slashpackage, the user would also need ./package/compile and ./package/upgrade scripts that can build the software and install it locally.
notqmail could have an --enable-slashpackage option, similar to skarnet's skalibs/execline/s6 software which allows for slashpackage-style building and deployment. To avoid forcing slashpackage format on everyone, the compile and upgrade scripts could probably live in a subdirectory of the repository. For example, we could move the notqmail source into a ./src subdirectory, which is commonly seen in software projects, and put slashpackage details and script into, for example, ./contrib/slashpackage.
If we intend to make notqmail compliant with the usual "./configure && make && sudo make install" mantra, it could also allow for "./configure --enable-slashpackage && ./package/compile && sudo ./package/upgrade".
slashpackaging qmail - experimental notes
I've converted netqmail-1.06 into an experimental slashpackage that seems to work as expected. Binaries are still installed with a lightly edited hier.c that puts them into "/package/mail/netqmail-1.06/commands" with their necessary ownership and modes. In the same way auto_qmail.h reads ./conf-qmail, I added an auto_slashpackage.h that reads ./conf-slashpackage at compile time. (This is a chicken and egg problem. If your /package dir is really in, say, /var/package, you would need to edit this file after extracting the source under /var/package before you can successfully compile it.)
Platform note: On OpenBSD the /var partition is by default mounted with the "nosuid" option, which breaks qmail-queue. If I do not mount /package under /var, this saves me a deployment gotcha that I've only been tripping over for about 15 years. If I can avoid a dedicated /var/qmail partition, and I don't have to guesstimate the maximum allowable size of my mail queue, and I don't need to reserve that much disk space on the machine for no other purpose -- forever -- then that makes me happy.
With the qmail-* binaries installed under /package, I then symlink them into /var/qmail/bin so that the system can still find them as needed. Unlike a normal slashpackage deployment, I do not symlink these commands into /command and then symlink those links into /usr/local/bin for the same reason I don't put /var/qmail/bin into the default user path. This is personal preference and may go against the spirit and letter of the slashpackage law.