bin/run has no install option, despite comments

[Senso]

bin/run has this in its header:

# DO NOT use this script as a system startup tool (eg. in /etc/init.d,
# /Library/StartupItems, launchd plists, etc.)
#
# For those uses, install the server properly (eg. with "./run -i
# /tmp/foo && cd /tmp/foo && pax -pe -rvw . /") and use the caldavd
# executable to start the server.

The script does "accept" the -i switch (echo "Usage: ${program} [-hvgsfnpdkrR] [-K key] [-iIb dst] [-t type] [-S statsdirectory] [-P plugin]"; but there is nothing in the run script doing anything about it. The case "${option}" block has nothing for -i/-I.

So what are we supposed to do if we do indeed want to use it with init.d or Systemd? What would be the proper "install" procedure? At the very least, the run script should be amended to remove that comment from the header, to avoid false hopes.

[dreness]

The -i switch is indeed old and vestigial, so we should remove it. ./bin/package (despite the name) will produce a dstroot-based "install". I put "install" in quotes because it is not a complete solution in that it does not include all the dependencies required by CalendarServer - if I recall correctly, it might not get any deps that are both build deps and runtime deps (virtualenv for example), but should get all of the runtime-only deps. The 'package' script was written to ease the process of building on machine A and then deploying on machines B through Z which are all running the same OS and with similar environmental conditions. The workflow there is basically: run ./bin/package targeting a specific path, archive the target directory, deploy that archive on the app servers AT THE PREVIOUSLY SPECIFIED PATH, and configure the app servers to load the environment.sh file that is produced by ./bin/package and installed into the dstroot.

The main reason for the advice about not using 'run' is that this script is intended to help bootstrap the environment for development / testing, possibly making changes to do so, which is probably not what you want when running in production. You could also run ./bin/caldavd directly from a git checkout, but again for any kind of serious use I would recommend against any configuration that might allow the code to be easily or accidentally changed.

[dreness]

I updated Guide.rst with a summary of the above.