Add add-package persistence

[max312]

caddy "add-package" will not persist upgrades

my idea would be to add a file that lists additional packages, which is read by the install-scripts or the init-scripts.

[francislavoie]

This is what these steps are for: https://caddyserver.com/docs/build#package-support-files-for-custom-builds-for-debianubunturaspbian

To clarify, the packages are persisted because the packages are in the current binary. The problem you have is that you didn't make a diversion when you started using a custom binary, so updating with apt resets to a vanilla binary.

I don't think it makes sense to have the apt repo care about plugins at the moment. You should just set up a diversion.

[max312]

This is what these steps are for: https://caddyserver.com/docs/build#package-support-files-for-custom-builds-for-debianubunturaspbian

To clarify, the packages are persisted because the packages are in the current binary. The problem you have is that you didn't make a diversion when you started using a custom binary, so updating with apt resets to a vanilla binary.

I don't think it makes sense to have the apt repo care about plugins at the moment. You should just set up a diversion.

Thanks for pointing there.
I must admit, i haven't seen it before, as I am mainly using Fedora/CentOS Distributions.

I think it would be necessary to add modularity on distribution level by providing such a "binary-builder" inside the packages?
Otherwise specifying on how to reproduce this on RPM-based distros?

[francislavoie]

Fair enough, I don't have a recommendation because I don't use RPM myself and don't know what kind of diversion mechanism exists there.

@carlwgeorge @Conan-Kudo if you have ideas?

[mholt]

I'm confused, when you add-package, caddy calls for a build with all the existing packages plus the new one(s). This is persistence, no? caddy upgrade also persists the plugins.

[max312]

I'm confused, when you add-package, caddy calls for a build with all the existing packages plus the new one(s). This is persistence, no? caddy upgrade also persists the plugins.

I updated caddy from package repository (fedora copr) and my caddyserver was down because my Caddyfile contained configuration from a plugin added by add-package.
Hope this clarifies my "persistence"-perspective better ;-)

[mholt]

Oh, right, so mixing Caddy package management and OS package management is not going to be compatible (thanks to limitations in OS package managers not supporting HTTP calls for downloading the binaries), but yeah Francis linked to a viable alternative for Debian... curious if there's anything similar for RPMs.

[max312]

Oh, right, so mixing Caddy package management and OS package management is not going to be compatible (thanks to limitations in OS package managers not supporting HTTP calls for downloading the binaries), but yeah Francis linked to a viable alternative for Debian... curious if there's anything similar for RPMs.

I wonder if os-package managers can call caddy itself in post-install-scripts? Is there a persistence of add-packages outside of its own binary?
Or is there the possibility to add an exporter for those packages to call as pre-upgrade-script in OS-PM and later call add-package on that again?

[francislavoie]

The other option is to copy your custom caddy binary to /usr/local/bin which would shadow the /usr/bin one managed by the distro. That way updating the package doesn't reset your binary. But doing that won't make the systemd service work with the new binary because it points directly to /usr/bin/caddy so you'll need to set up an override for that too https://caddyserver.com/docs/running#overrides.