An xcaddy build hook for system packages

[p0358]

I have an idea, hear me out. Would've maybe PR'd it, but I have no idea how goreleaser works or how to structure it as such.

Right now a big pain point with using any Caddy modules is that you have to use and invoke xcaddy manually, which means there's no way to automatically receive updates when doing apt upgrade, and have to explicitly remember about it (or more realistically, just run old Caddy forever until someone remembers, which isn't great for security -- if only the person would even remember the xcaddy command they ran originally).

I thought of one solution to that: setup a meta-package like xcaddy-hook, that'd set up a dpkg trigger to watch /usr/bin/caddy being updated by APT (as a sort of notification that update was received), then it'd invoke a build script that user would put, say, in /etc/default/xcaddy. It could then even automatically set up a dpkg-divert as described in the docs, so the whole process could be pretty seamless to the user.

What do you think?

For triggers you'd ship a file DEBIAN/triggers with interest /usr/bin/caddy (or perhaps rather interest-noawait) in it, and that'd invoke DEBIAN/postinst with $1 argument of triggered, where it could run source /etc/default/xcaddy in turn.

Then DEBIAN/control would be something like that and that'd basically be the whole package:

Package: xcaddy-hook
Version: 0.1
Maintainer: Matthew Holt <mholt@users.noreply.github.com>
Architecture: all
Description: Build Caddy with plugins (TODO change desc)
Depends: caddy, xcaddy

It could in theory for simplicity even be just a part of the main xcaddy package and be conditioned based on the presence of /etc/default/xcaddy file...?

[francislavoie]

Sounds like a neat solution to me if you want to take a shot at building it out. I don't know enough about all these debian details and I haven't been interested to learn it so we just did the bare minimum. But as long as it's an optional trigger like you mention then that certainly sounds fine to have.

Keep in mind though, there's no guarantee that the xcaddy build will succeed though, because a change in Caddy core may cause a plugin to break and also need an update, in some cases, and those plugin updates have to be released after the Caddy release (plugins are dependent on Caddy itself for the interfaces) and there's the human factor of having maintainers make the necessary changes ASAP etc. So yeah, build output and errors definitely should be shown and are possible in this setup.