On 2021-09-28 at 10:27:12 UTC-0400 (Tue, 28 Sep 2021 16:27:12 +0200) Gerben Wierda via macports-users <gerben.wie...@rna.nl> is rumored to have said:
> A while back I have done a lot of cleanup, using looking at dependents, > reinstalling stuff so it no longer depends on, say, older versions of python, > etc. > > Now, recently I’ve started reaching certbot/letsencrypt warnings that my > certificates are about to expire. I used to have a fully automatic setup that > did the updates in the background. Apparently, that has died. And it turns > out certbot doesn’t work anymore because some part of python is missing: > > Traceback (most recent call last): [...] > > Other than that the cleaning up has removed chardet. Looking at chardet in > what is available, I find: > > py39-cchardet @2.1.7 (python, devel, textproc) > cChardet is high speed universal character encoding detector. > > py39-chardet @4.0.0 (python, devel, textproc) > Universal character encoding detector > > I suspect I need the chardet extension. > > What is the way to find this out using a port command? In principle, 'port rdeps <portname>' will show you a recursive tree of dependencies for any port. Also, 'port rdependents <portname>' will show you all ports that are dependents (recursively) of any *installed* port. In practice, those are sometimes not exactly correct, because they depend on port maintainers noticing dependencies and stating them in the Portfile. For example, the error message you showed implies that certbot depends on chardet indirectly via the acme package, but that is not reflected in the MacPorts dependency map. The Changelog for certbot indicates that this dependency was added upstream in v1.18.0 and removed in 1.19.0, so the current MacPorts dependency map is correct not to show it NOW, but for most of August, that dependency existed in the code but not in the Portfile. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
