Bug 2360992 - rpm 6.0 pulls gnupg2 and a dozen dependencies into minimal rawhide buildroot
Summary: rpm 6.0 pulls gnupg2 and a dozen dependencies into minimal rawhide buildroot
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-04-18 15:56 UTC by Fabio Valentini
Modified: 2026-01-16 20:47 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.