[citest]

On current rawhide, it generates:

rpm -qR results_gnutls/3.7.6/6.fc37/gnutls-3.7.6-6.fc36.x86_64.rpm | grep '^\(nettle\|gmp\)'
gmp(x86-64) = 6.2.1-1.fc36
nettle(x86-64) = 3.8-1.fc37

Neat, didn't know it was possible. Less explicit to the reader, but I like the foolprofing. r+

Wait no, I take it back...

If a builder happens to be a multiarch machine, rpm will list the package version twice, resulting in an invalid version.

(a multiarch machine with two versions of the package coinstalled)

Yeah, good point; I've changed the selection option from -qa to -q --whatprovides 'nettle(x86-64)'.

Should be fine now, r+

Ah, so the idea is that bodhi/installability tests etc. won't import a new package into -updates or CentOS/RHEL as long as gnutls-fips is uninstallable? That could help indeed.

I just have to ask: Why not simply tighten the dependencies on gnutls itself? It already depends on gmp and nettle, so this doesn't reduce the dependencies that way. (If the above works that seems ok to me, I'm just curious why this is better)

Thanks!

(Build failed with error: Package has no %description: gnutls-fips, BTW)

I just have to ask: Why not simply tighten the dependencies on gnutls itself? It already depends on gmp and nettle, so this doesn't reduce the dependencies that way. (If the above works that seems ok to me, I'm just curious why this is better)

That was actually the original approach here, though I wanted to start with a limited scope (i.e., non-FIPS consumers are not affected), because I find it quite hackish to generate Requires: with lua/rpm during rpmbuild. If it turns out reliable, we could merge it into the main package.

(Build failed with error: Package has no %description: gnutls-fips, BTW)

Thank you for spotting this; I've fixed it along with a couple of other issues.

Minor update: @hkario suggested keeping "Requires: nettle >= 3.9.1" in the base package as it wouldn't hurt to have multiple Requires as long as they are treated as AND. I updated the PR along that line.

r+

r+

Not much differs from 1e09d22, so I've focused on the aspect of not locking the package with hmacs directly to the referenced nettle and gmp, but rather binding the three together with an fourth, newly introduced package. That seems to hold.

Scenarios I've tested:

1. an attempt to update nettle with gnutls-fips installed is inhibited with package gnutls-fips-3.8.5-1.fc40_fingertip.x86_64 from @System requires nettle(x86-64) = 3.9.1-6.fc40, but none of the providers can be installed

2. an attempt to install a mismatching gnutls alongside a gnutls-fips of a different version is installed is inhibited with

- package gnutls-fips-3.8.5-1.fc40_fingertip.x86_64 from @System requires gnutls(x86-64) = 3.8.5-1.fc40_fingertip, but none of the providers can be installed
- package gnutls-fips-3.8.5-1.fc40_fingertip.x86_64 from fingertip-local-gnutls requires gnutls(x86-64) = 3.8.5-1.fc40_fingertip, but none of the providers can be installed

Thanks for checking; merging this now!