Bug 1404281

I am actually trying to work around #1402784

Here's the problem:

[pmatilai@sopuli dist]$ rpmspec -q --buildrequires openconnect/openconnect.spec 
warning: Macro expanded in comment on line 12: %make_install macro

error: Unable to open /home/pmatilai/rpmbuild/SOURCES/macros.gpg: No such file or directory
error: query of specfile openconnect/openconnect.spec failed, can't parse
[pmatilai@sopuli dist]$ 

I was about to say this is an rpm bug, it's supposed to ignore missing sources in spec parse, but the problem here is this:
%include %SOURCE3

Rpm tries to include it from %_sourcedir, but that defaults to ~/rpmbuild/SOURCES and since SOURCE3 (macros.gpg) is not there it fails. The difference here is that an average source is not relevant for parsing the spec, but an %include is, so it cannot be ignored like other sources.

If you tell what the source dir is, it works:
[pmatilai@sopuli dist]$ rpmspec --define "_sourcedir openconnect" -q --buildrequires openconnect/openconnect.spec
warning: Macro expanded in comment on line 12: %make_install macro

Found source: openconnect/openconnect-7.08.tar.gz
Found source: openconnect/openconnect-7.08.tar.gz.asc
Found keyring: openconnect/gpgkey-BE07D9FD54809AB2C4B0FF5F63762CDA67E2F359.asc
Found source: openconnect/macros.gpg
No common key yet
Using first found keyring file: openconnect/gpgkey-BE07D9FD54809AB2C4B0FF5F63762CDA67E2F359.asc
------------
autoconf
automake
gettext
gnupg2
krb5-devel
libtool
pkgconfig(gnutls)
pkgconfig(liblz4)
pkgconfig(libpcsclite)
pkgconfig(libproxy-1.0)
pkgconfig(libpskc)
pkgconfig(libxml-2.0)
pkgconfig(socket_wrapper)
pkgconfig(stoken)
pkgconfig(uid_wrapper)
python
trousers-devel
[pmatilai@sopuli dist]$

Only there's no way to do that with dnf builddep.

It's one of those cases where everything is behaving correctly but somehow it ends up not working :) %include in spec is problematic from parsing POV, because generally a spec can be parsed as an independent entity but %include introduces local paths into the picture.

In this particular case, the %include is only needed during build (%prep) but and the issue could be avoided by writing the spec differently, eg something like:

%if 0%{?gitcount} > 0
%include %SOURCE3
%gpg_verify
%endif

But that's just an exception, the expected use of %include is to construct parts of the spec so it can't be just ignored.

Hm, I thought that's how we were supposed to use this until it landed in the default macros. Tibbs?

Actually my "workaround" only works because it disables the whole thing so not the most thought-out workaround ever, sorry about that. The bottom line is %include is somewhat problematic, and in this case the whole thing would be better off written as a shell-script because it's only supposed to be executed during %prep.

We have introduced printing rpm error if spec parsing fails, so it should be improved UX.

Unfortunately dnf can't do more about this.