Where the preferred situation is to use the distributions official package manager to install certbot. Then any dependencies should be resolved by the package manager and nothing else.
Ahem… Well, if there is such a package in the distribution’s repository, that is.
I happen to be “lucky” since I use Gentoo Linux. Our package system ‘portage’ used to have the ‘letsencrypt’ package in a few versions. Now we have the ‘certbot’ package available. We thereby have a supported “upgrade path” from ‘letsencrypt’ to ‘certbot’.
Of course, not all distributions have and do this. The right way would, for most distributions, be to file a ‘package request’ in the distributions ordinary way, like for instance through Bugzilla or what have you for the distro in question.
Only if this is not possible, or if it’s way too slow to get a package within a reasonable time frame, would I go for a git pull. (Or maybe if I needed to overcome some limitation in the normally distributed package by using the latest, greatest and least tested, “still smoking” software from git.)
Having a distribution-provided ‘official’ package installed also means that in some 99+ % of the cases, you don’t want to have any software update itself, through ‘certbot-auto’ or equivalent means. That would totally brake your software maintenance routines. A later “official” upgrade could actually become a downgrade from a ‘git’ package to the distro’s latest package. Personally, I’d be very, very careful not to use that kind of “self-upgrading” software. But yes, I can say so because I happen to be so lucky to have an “official” upgrade path in my distro.
I would encourage any CentOS users to push for an “official” CentOS package of ‘certbot’ as soon as possible. Likewise for any other distribution lacking the ‘certbot’ package.
Finally, with the change of ownership of the Let’s Encrypt client software, I believe we should probably start discuss the new ‘certbot’ client on EFF’s support forum. EFF is responsible for the client now.
Yet another reason why Let’s Encrypt should better describe the ‘three-tier’ design of:
-
LE as a CA service
-
The multiple clients to obtain a cert, built, maintained and documented as different initiatives by several different organizations.
-
The configuration of all kinds of different Web servers to use the obtained certificate. This will most likely require at least a minor tweak by a human being before it’s fully functional.