Bug 1293687

Today I hit a rare condition with a spec file that gives an error when issuing:

rpmspec --query xfce-polkit.spec

https://bugzilla.redhat.com/show_bug.cgi?id=1281464#c26

The file that causes the error is found here:

http://pkgs.fedoraproject.org/cgit/xfce-polkit.git/plain/xfce-polkit.spec

The patch0 section here contains an URI, that directs to an external patch on a different platform / server (git).

Unfortunately issuing above query command returns an error because (what I believe) of rpmspec not being able to deal with that.

We do have an own build farm here that builds (and rebuilds) different parts of Fedora, so we can customize the stuff for our needs and requirements.

We have an own build tools and build scripts that heavily depends on external tools such as rpm-build and rpmspec --qery (or --parse).

The stuff runs well for the past couple of years, until this new issue has shown up.

We usually grab the *.spec files first, so we can process them with the rpmspec --query util, which returns the - to be build - resulting packages (incl. NEVRA). The output is being processed elsewhere and we continue building the stuff with rpm-build as needed.

Now the indepth problem:

We do deal with plenty of spec files that way. Say for example:

rpmspec --query exo.spec
rpmspec --query Thunar.spec
rpmspec --query xfce-polkit.spec

and so on...

We rpmspec these files before we do anything else with them. So during that time we only have the *.spec files. No patches! Nothing!

Plenty of these spec files do have references to external patches (but they are referenced inside the spec files as normal plain filenames). We now hit a special condition inside xfce-polkit.spec where the patch has been referenced as URI. And here rpmspec fails (... and expects the patch in the SOURCE folders). But running rpmspec on the other spec files are not going to error and thus don't expect anything else.

After some RPM.org studying I found out that the the patch section allows the URI reference for patch files and thus using URI within patch section is ok.

http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html

Search for "the patch tag"

QUOTE: "RPM processes patch tags the same way it does source tags. Therefore, it's acceptable to use a Uniform Resource Locator (URL) on a patch line, too."

Now it would be nice, if rpmspec would deal the same way with external URI references than with local files within the patch section.

Or simply said:

We want to continue issuing

rpmspec --query some.spec

and not being bothered with errors of missing patch files in some source directory. Otherwise we would expect the same errors to show up with any spec file that has 1 or more patch sections embedded (but referenced as files). Even downloaded or not.

https://bugzilla.redhat.com/show_bug.cgi?id=1281464#c26