[Fedora-packaging] Re: Macro expansion problem

Jarod Wilson jwilson at redhat.com
Tue Aug 26 18:35:51 UTC 2008


On Tuesday 26 August 2008 13:47:42 Axel Thimm wrote:
> On Tue, Aug 26, 2008 at 01:39:00PM -0400, Michel Salim wrote:
> > On Tue, Aug 26, 2008 at 7:46 AM, Rex Dieter <rdieter at math.unl.edu> wrote:
> > > Michel Salim wrote:
> > >> At the risk of asking the obvious, why does this fail:
> > >>
> > >> %define nunitver %(gacutil -l nunit.core | tail -n 2 | grep nunit.core
> > >>
> > >> | cut -d "=" -f 2 | cut -
> > >>
> > >> d "," -f 1)
> > >>
> > >> Requires: mono(nunit.core) = %{nunitver}
> > >
> > > I'll venture because our buildsys needs to (re)generate the srpm, and
> > > at that time, no BR's are installed and gacutil isn't available =>
> > > failure. To protect against that, do something like:
> > >
> > > %define nunitver %(gacutil -l nunit.core 2>& /dev/null | ...)
> > >
> > > %if "x%{?nunitver}" != "x"
> > > Requires: mono(nunit.core) = %{nunitver}
> > > %endif
> >
> > Axel: It fails by being empty.
> >
> > Tom, Rex: as Rex said, it is because BRs are not installed when the
> > SRPM is regenerated (perhaps we need a different directive, like
> > PreBuildRequires: ? Hmm)
> >
> > So in this case, nunitver will *always* be empty, so I'm not sure how
> > the test will help.
>
> This idiom is often used with perl/python/php etc. The first phase
> creating the src.rpm will be giving you some warnings, but the second
> phase, the actual building of the binaries will have the bits in place
> due to the BuildRequires, so it will not be empty then.

Indeed. Scope out this snippet from rrdtool:

# eval to 2.3 if python isn't yet present, workaround for no python in fc4 
minimal buildroot
%{!?python_version: %define python_version %(%{__python} -c 'import sys; print 
sys.version.split(" ")[0]' || echo "2.3")}

As the comment suggests, python wasn't part of the minimal buildroot in fc4, 
so during the re-creating the srpm stage, the '|| echo "2.3"' part of the 
macro set a BR on python >= 2.3 initially when python wasn't yet there, then 
when the actual build started after mock had installed all the BR, it 
evaluated to the proper version for the dist. Same sort of thing should work 
for you.

Note to self: that can probably be dropped from rrdtool now, since fc4 ain't 
exactly supported anymore...

-- 
Jarod Wilson
jarod at redhat.com




More information about the Fedora-packaging mailing list