Maxim Cournoyer <maxim.courno...@gmail.com> writes: > Hello, > > Liliana Marie Prikler <liliana.prik...@gmail.com> writes: > >> Am Montag, dem 13.05.2024 um 22:38 +0100 schrieb Christopher Baines: >>> I've seen this when updating systems, but it seems like something is >>> wrong with the handling of nss-certs. >>> >>> I'm on a guix revision with nss-certs by default, and when I add >>> nss-certs to my system packages (to simulate not removing it when >>> upgrading), it breaks certificates (e.g. wget https://guix.gnu.org/ >>> doesn't work). >> I can confirm this on three machines (two of my own, one from a >> relative): Having nss-certs in the packages field unexpectedly breaks >> all known certificates. >> >>> My reading of the operating-system-packages code suggests that adding >>> nss-certs shouldn't have any effect, but this doesn't seem to be >>> working. >> It would be really nice to detect the mismatching versions if it's >> based on that. IIUC we graft nss-certs now, so that we can hot-swap >> stuff like pythons certifi package. Is this use case broken by any >> chance? > > Apparently having multiple nss-certs of the same version is no problem > (they get deduped later). The original problem would thus only exist > when there are multiple versions of nss-certs listed in packages, as > could happen for installer-generated configs that use > '(specification->package "nss-certs"), which would pick the latest > version and clash with the one in %base-packages. > > My code could call delete even in the first case, which would clear > *all* nss-certs because they were the same object. That's now guarded > against in 35ae95061e1b843e1df069693177519f22f9a16d ("system: Do not > delete all nss-certs packages when they are the same object."), which > I've just pushed.
Great, thanks for fixing this Maxim! Chris
signature.asc
Description: PGP signature
