Continuing the tangent of https://github.com/mholt/caddy/issues/1565
I think having system init scripts in the repo is actually an ideal solution. It's very open-source-y, gives great visibility to the process for others wanting to do it for multiple systems, etc.
I don't think Caddy should go into the distro repositories. They'll just screw it up and the updates will be slow and it will be a nightmare - just like it has been for jquery, node.js, ruby, and go proper. There's always version issues, plugin issues, etc.
Distros should be for OS level packages and these fun and new types of things are just too fast moving to be updated in 50 different places.
However, having an install install.sh and install.bat that gets updated in one place to support the 6 most common OSes or so (win, mac, debian (ubuntu, mint), redhat (fedora, centos), arch, freebsd) would be a great precursor to having a managed installer (much like the old flash install script installers) as was noted on the forum.
I could create an installer that would follow the necessary steps to produce a working configuration the first time every time and print out some help messages like this:
The caddy service has been installed and is running. If you'd like to manually start, stop, or check the status of it you can do so:
systemctl start caddy.service
systemctl stop caddy.service
systemctl status caddy.service
If you need to debug the caddy service (i.e. perhaps something is wrong with your Caddyfile) run this:
sudo -u www-data CADDYPATH=/etc/ssl/caddy /usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp
If you need to reset the permissions this
find /etc/caddy -type d -exec chmod 700 "{}" \;
find /etc/caddy -type f -exec chmod 600 "{}" \;
Or something like that. But it should Just Work (TM) if someone hasn't done any custom setup on their system.
Distros should be for OS level packages and these fun and new types of things are just too fast moving to be updated in 50 different places.
My understanding is that projects can create their own repos and update them as often as they please. But I've never done it before, so I may be wrong.
But, if it's the case that we can update them as often as we want, does that change anything?
You mean like a PPA?
Sure you can, but then in order to run sudo apt-get install you have to add a key to the keychain and a PPA first... so at that point you're back at needing to make it easy to install.
1 command is simpler than 4. Every time. 4 may be more technically correct, but sex sells and so do 1-line copy-n-paste examples.
I mean, sure, why not put in the extra effort. But if you can make it easier for an end user with less effort... why not take the easier route that serves a broader audience first (and do the more difficult thing that benefits fewer people later)?
(and some people make the deceptive argument that a package is more secure if it has a sha256 or whatever... but if you're making a build building package then only your build builder is sha256'd and aside from that sudo curl is just as safe as sudo add-apt-repository ppa:<repository-name> - as in it's completely not unless you trust the source in the first place)
Some users depend on their distro for notifying them of updates and security patches.
For arch it doesn't make sense not have an AUR package that simply runs the installer scripts.
There has been a related debate on the caddy forums https://forum.caddyserver.com/t/packaging-caddy.
I don't like the idea of having the install.sh script. Since it will not integrate with existing package managers users will install it once and update never (or you have to resort to nasty automatic update tactics, please don't). The overhead for a user to add a PPA is not that large and can be a one liner as well, but has the advantage that caddy will actually be updated along with other OS packages.
I'm working on an installer script. If you guys would like to accept it, you can have it. (I'll post back when I've got something)
The issue is "having something that people can use now that will actually solve their current problems" vs "not having that something and waiting for a theoretical day when contributors will come out of the woodwork to solve it".
I personally much prefer software that can hot-update itself rather than relying on a system manager. libc is one thing, my applications and services are another.
i.e. If my web browser is evergreen... shouldn't my webserver be also?
(also note that my web browser doesn't break everything when it updates - I also like that about it)
TADA!
https://git.daplie.com/Daplie/caddy-installer
Sure there can be some nits about the particular ways of using this or that in bash, but it's a dang good start and it has nice commandline flags to boot.
The installer has been updated to work with the new site. :)
(Ignore any comment notifications you may have gotten from a user account that looked like mine earlier today.)
Most helpful comment
There has been a related debate on the caddy forums https://forum.caddyserver.com/t/packaging-caddy.
I don't like the idea of having the install.sh script. Since it will not integrate with existing package managers users will install it once and update never (or you have to resort to nasty automatic update tactics, please don't). The overhead for a user to add a PPA is not that large and can be a one liner as well, but has the advantage that caddy will actually be updated along with other OS packages.