Hi,
First of all, thanks for the great work on caddy.
I would like to start by saying that the current packaging solution is really appreciated and solves the problem of most users, and this issue aims in proposing a solution to also bring the work in packaging to the users building custom binaries.
My experience in packaging software is limited, the intention of this proposal is to bring the case to the attention of the maintainers that have more experience than me.
On the community discord we had a case where the user had some issues deploying a custom-built caddy
to his server and the error messages sent me down the wrong rabbit hole which triggered some discussion on how to avoid such a thing to happen again and to make the experience more pleasant for the users building custom binaries.
I did test some of the options below, except for the one splitting caddy
into multiple packages.
Problem statement:
Any user that utilizes xcaddy
to build custom binaries, will also be forced into a position that they need to manage other operational system configurations by themselves, like for example the default configuration and systemd service definition.
One can states that any user utilizing xcaddy
should be considered an advanced user, and this should not be a problem, but there are some cases where this can cause trouble even for advanced users to troubleshoot.
For example ReadWriteDirectories
configuration on systemd, if any directory is missing, caddy
will throw a 'read-only file system' error instead of an access denied
or even a more descriptive error, which usually sends into a completely different troubleshooting path.
But considering how much work and thought was put into xcaddy
to make the experience pleasant and seamless to users, I assume that this is something that would be welcomed to be discussed.
Options:
There are multiple options on how to solve this issue and provide a better experience for users that want to build custom binaries.
Just let users install the package and replace binaries
xcaddy build ...
cp ./caddy /usr/bin/caddy
Pros:
- Simplest possible solution
Cons:
- This will break package upgrades
- It can trigger alerts for HIDS that uses package checksums
- It's not the standard way to handle such configuration on Debian based distributions
dpkg-divert
dpkg-divert --divert /usr/bin/caddy.default --rename /usr/bin/caddy
xcaddy build ...
cp ./caddy /usr/bin/caddy
Pros:
- Does not require any changes from package maintainers
Cons:
- Requires user knowledge and documentation
- It's not the standard procedure for other packages, it's considered more of a workaround.
update-alternatives
xcaddy build ...
cp ./caddy /usr/bin/caddy.custom
update-alternatives --install /usr/bin/caddy caddy /usr/bin/caddy.custom 10
Pros:
- It's a behavior that is a little bit more known and expected
- It allows users to easily move back and forth between binaries
Cons:
- It's a more common pattern when multiple packages that contains the same binary, like for example
vim.tiny
, and not for custom binaries
break caddy into two different packages, caddy and caddy-common
caddy
would bring the default binary, and caddy-common
just other distribution files, including systemd and default configuration.
apt install caddy-common
xcaddy build ...
cp caddy /usr/bin/caddy
Pros:
- It's simple and does not require much work from users, which will reduce human errors
Cons:
- This breaks backward compatibility with packages
- It requires more work from the packaging side
One point to note is that to avoid breaking backward compatibility, we can provide 3 packages, being caddy
a transitional meta-package that depends on both caddy-default
and caddy-common
this way we offer an upgrade path for users with older package versions.