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. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
