Bug 547997 - rpmbuild -bs became more strict and chokes on undefined macros in Requires
Summary: rpmbuild -bs became more strict and chokes on undefined macros in Requires
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-16 10:13 UTC by Jens Petersen
Modified: 2009-12-18 10:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-12-17 07:20:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jens Petersen 2009-12-16 10:13:50 UTC
Description of problem:
I can understand on BuildRequires but rpm now seems to need
to be able to expand macros in Requires to build srpms?

Version-Release number of selected component (if applicable):
4.8.0-0.beta1.3

How reproducible:
every time

Steps to Reproduce:
1. use macro like %ghc_version not defined in rpm or redhat-rpm-config (base)
   in package .spec file
2. try to build in dist-f13 in koji
3. job fails while generating srpm

Actual results:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1874770

Expected results:
Be allowed like in dist-f12?

Additional info:
We need ghc macros in rpm or redhat-rpm-config like we have for ocaml.
See ghc-rpm-macros package for %ghc_version and more.

Without fixing this we can't build ghc library packages for rawhide
and ghc-6.12.1 was just released so we need to rebuild them all.

Comment 1 Rex Dieter 2009-12-16 14:03:55 UTC
Fwiw, a workaround is easy enough.  For any undefined macro, say, %{foo}, change:
Requires: %{foo}
to
%{?foo:Requires: %{foo}}

This technique can be applied to BuildRequires as well.

Comment 2 Jens Petersen 2009-12-17 01:29:54 UTC
(In reply to comment #1)
> Requires: %{foo}
> to
> %{?foo:Requires: %{foo}}

Thanks Rex that helps a lot actually. :)
It has given me enough ideas to experiment a bit
- perhaps after that I may be able to close this actually.

Comment 3 Panu Matilainen 2009-12-17 07:20:11 UTC
Yup, this is one of the fundamental chicken-and-egg problems with spec files: there's no guarantee that a spec can be correctly parsed if build-requires are missing, but in order to parse out build-requires from the spec, rpmbuild needs to be able to parse the entire spec...

Generally, if there's a chance for a macro to be undefined, the spec should be written to deal with it somehow. The approach shown by Rex works fine for Requires and many others, but with BuildRequires it can cause the BuildRequire that would correct the situation to be missed. Another variant that avoids that would be
BuildRequires: ghc %{?ghc_version:= %{ghc_version}}

Anyway, I've loosened up the new checks to permit unexpanded macros to slip through the valid character checks until we have a better fix for this. Built into 4.8.0-0.beta1.4 in rawhide now.

Comment 4 Jens Petersen 2009-12-18 10:12:41 UTC
Ah thanks that saves we having to write extra ghc macros for now then. :)

http://koji.fedoraproject.org/koji/buildinfo?buildID=147621


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