Bug 2360992

Summary: rpm 6.0 pulls gnupg2 and a dozen dependencies into minimal rawhide buildroot
Product: [Fedora] Fedora Reporter: Fabio Valentini <decathorpe>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: code, igor.raits, mdomonko, ngompa13, packaging-team-maint, pmatilai, ssorce
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Fabio Valentini 2025-04-18 15:56:15 UTC
It looks like rpm-sign-libs is now a hard dependency for rpm since 6.0 alpha.

And rpm-sign-libs has a hard dependency on gnupg2, which now pulls in a *lot* more packages into the minimal buildroot:

- gnupg2
- gnutls
- ima-evm-utils-libs
- libassuan
- libfsverity
- libgcrypt
- libgpg-error
- libksba
- libusb1
- nettle
- npth
- rpm-sign-libs
- tpm2-tss

This seems unfortunate, given that the rest of the packaging stack has dropped dependencies on gnupg2 / gpgme (rpm, dnf, etc.), and increases the size of the minimal buildroot substantially.


Reproducible: Always

Comment 1 Panu Matilainen 2025-04-22 06:48:29 UTC
rpm-sign-libs is not a dependency of *rpm*, it's a dependency of *rpm-build*. But yeah that would affect the minimal buildroot somewhat.

The hard dependency on gnupg2 is kinda wrong now though, it could now be "gnupg2 or sequoia-sq". The latter pulling considerably less fubar with it, but since the choice between gnupg/sequoia is a user configurable thing, expressing it through dependencies isn't going to work well.

Comment 2 Panu Matilainen 2025-04-22 11:41:36 UTC
Maybe the build-time autosigning feature should just use dlopen() instead of linking to librpmsign and just have a recommends on it instead, that'd basically put us back to the previous situation.

The gnupg/sq dependency issue within rpm-libs-sign is a kind of a separate issue.

Comment 3 Fabio Valentini 2025-04-22 12:38:45 UTC
> since the choice between gnupg/sequoia is a user configurable thing, expressing it through dependencies isn't going to work well

In that case - would it make sense to depend on *neither*, and let users pull in the dependency manually that matches their configuration?

Comment 4 mickilangelo 2025-05-15 15:45:58 UTC Comment hidden (spam)
Comment 5 monkaw33333 2025-05-28 00:14:06 UTC Comment hidden (spam)
Comment 6 Timothee Brown 2025-06-19 12:17:59 UTC Comment hidden (spam)
Comment 7 Clifton 2025-08-05 16:34:38 UTC Comment hidden (spam)
Comment 8 stavr24242 2025-08-06 18:38:45 UTC Comment hidden (spam)
Comment 9 Alex 2025-08-23 20:43:24 UTC Comment hidden (spam)
Comment 10 rixydaa 2025-09-19 22:02:20 UTC Comment hidden (spam)
Comment 11 Simo Sorce 2026-01-16 16:45:28 UTC
(In reply to Panu Matilainen from comment #1)
> rpm-sign-libs is not a dependency of *rpm*, it's a dependency of
> *rpm-build*. But yeah that would affect the minimal buildroot somewhat.
> 
> The hard dependency on gnupg2 is kinda wrong now though, it could now be
> "gnupg2 or sequoia-sq". The latter pulling considerably less fubar with it,
> but since the choice between gnupg/sequoia is a user configurable thing,
> expressing it through dependencies isn't going to work well.

Shouldn't this be addressable by a provides (let's call it "rpm-signing") in gnupg2 and sequoia-sq and ten have rpm-build depend on "rpm-signing" instead of gnpg2 ?

Comment 12 Fabio Valentini 2026-01-16 20:47:14 UTC
As far as I can tell, this has the same problems as "Requires: (gnupg2 or sequoia-sq)", just with extra steps.
And in both cases, there is either an an implicit (alphabetical?) or explicit (Suggests: ...) preference.