On 19/01/2026 14:57, Neal Gompa wrote:
On Mon, Jan 19, 2026 at 8:45 AM Petr Menšík <[email protected]> wrote:
On 19/01/2026 14:04, Neal Gompa wrote:
Ehh, it happens. I just switch back as part of replying in-line.
Also: %{gpgverify} is the macro we use to verify signatures. Something
has to provide that macro, and something has to provide what that macro
needs.
RHEL >= 9 has %{gpgverify} already. That is not the problem. Problem is it
requires different package to provide it. In RHEL that macro is provided by
redhat-rpm-config package, where also verification script very similar to the
gpgverify lived.
I would have to put into spec special conditions, if I want to build the same
spec with the older RHEL too. Something like:
%if 0%{?rhel} >= 9 && 0%{?rhel} < 11
BuildRequires: gnupg2
%else
BuildRequires: gpgverify
%fi
But perhaps we can only add Provides: gpgverify into existing gnupg2 package on
RHEL < 11. Everything else can remain unmodified and it would allow to build
Fedora spec files also for RHEL10 or RHEL9, where %{gpgverify} macro is already
present. Even without EPEL repository enabled.
It would need a higher version of gpgverify to be preferred, which it is not
higher now. I think using epoch in gpgverify or using intentionally lower
version in Provides: gpgverify = 0.%{version} from gnupg2 spec should solve it.
That should ensure epel version is chosen when epel repo is available, but
would build even with RHEL/CentOS repositories only.
If CentOS does not have gpgverify then that is where the problem needs be
solved. Abstracting things (in a macro and a single-purpose package) but
than "require"ing a concrete implementation and full suite from each
package was never right.
RHEL9 and RHEL10 are red herrings for any discussion about the present
and future of Fedora - simply because they are based on Fedora's past.
And regardless, if RHEL or EPEL really wants this, it'll get
backported eventually.
Adding a new RHEL component is not a simple process. It is even more
complicated than full Fedora Review. But maybe some workaround can be found,
like fake provides from gnupg2. That should be simple enough to create. I think
adding a 2 kilobytes of bash code is not probably worth it.
Created PR:
https://gitlab.com/redhat/centos-stream/rpms/gnupg2/-/merge_requests/19
Jakube, what do you think about such workaround? I think it will be sufficient,
unless gpgverify is added as a proper component to CRB repostory (and removed
from EPEL then). I think this way would be easier for everyone.
The easier thing to do would be to update redhat-rpm-config in RHEL,
not do weird things to the gnupg2 package.
Can you make example, what change in redhat-rpm-config in RHEL would
help? I want to have my rawhide branch spec file with latest version
built on CentOS 10, for example.
redhat-rpm-config on that version already provides %gpgverify macro, but
expects gnupg2 is in BuildRequires: of the spec. gpgv2 symlink to gpgv
is used by the shell script packaged in redhat-rpm-config.
I think we do not need changes to %gpgverify script, but in
BuildRequires. That never was in a form of macro and then cannot be
changed by macro definition.
Adding alias to gnupg2 package will ensure shell script in
/usr/lib/rpm/redhat/gpgverify can find gpgv2 even with BuildRequires:
gpgverify, according to latest Packaging guidelines. We do not have
separate guidelines for RHEL and look into Fedora's often.
This should be the most minimal way possible, improving the current
situation. Of course adding gpgverify to RHEL itself is a better
variant, but I would not call it minimal in that case.
--
Petr Menšík
Senior Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
