Some recent nss-certs changes have a negative side effects which
needs to be fixed.
A patch of mine was pushed recently (commit
0920693381d9f6b7923e69fe00be5de8621ddb6f), which adds nss-certs
3.98 to (gnu packages certs), under the nss-certs-3.98 variable.
Then, commit fdfd7667c66cf9ce746330f39bcd366e124460e1 was pushed,
which adds nss-certs to %base-packages-networking. This
references the nss-certs variable, which is version 3.88.1.
If an operating-system’s packages includes
`(specification->package "nss-certs")', this causes breakage,
because that form selects version 3.98, but %base-packages
includes 3.88.1, which causes an error on the next `guix system
reconfigure' due to conflicting package versions in the profile.
Prior to commit 65e8472a4b6fc6f66871ba0dad518b7d4c63595e, the
graphical installer would ask users if they wanted to install
nss-certs, and put this form into the operating-system’s packages,
so there are likely many users affected -- it bit me, and I’ve
seen a couple in IRC as well.
I think the options to fix this are:
1. Removing (specification->package "nss-certs") from one’s
operating-system.
2. Grafting nss-certs 3.98 onto nss-certs 3.88.1.
3. Replacing nss-certs 3.88.1 with 3.98.
The most expedient option is 1, as it can be applied by users --
but there’s probably not a good way to communicate that this needs
to happen.
There was some talk in IRC about grafting nss/nss-certs, but it
looks like this didn’t happen. An upgrade is the best path, but
would probably need to happen in core-updates, since this rebuilds
a large number of packages.
Thoughts on this?
Thanks,
— Ian
