Heads-up: %define vs %global in specs

Panu Matilainen pmatilai at laiskiainen.org
Tue Jan 5 19:58:52 UTC 2010


On Tue, 5 Jan 2010, Daniel P. Berrange wrote:

> On Tue, Jan 05, 2010 at 06:34:12PM +0200, Panu Matilainen wrote:
>>
>> For the impatient:
>>
>> Starting with today's rawhide, the these kind of constructs in specs
>> no longer "work":
>> 	%{?!foo: %define foo bar}
>> For the generally desired effect, the above simply becomes:
>> 	%{?!foo: %global foo bar}
>>
>> This is already recommended by the Fedora guidelines, but packages which
>> haven't been updated to follow the guideline might need revising:
>> https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
>
>
> What exactly do you mean 'no longer work' ? Can we expect to get a formal
> RPM build error for this bogus construct, or will it silently build and
> do the wrong thing ? From your long description, it sounds like the latter,
> which means maintainers should audit their spec files to identify these
> bogus macros

It depends on the details but most likely you'll get a build error of some 
kind as you'll get unexpanded macros where you previously got expanded 
macros (if you were lucky). For example

%{!?python_sitelib: %define python_sitelib %(python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
...

%files
%{python_sitelib}/mystuff.py

...would now error out at filelist processing stage as %{python_sitelib} 
is not defined in the global scope and literal 
"%{python_sitelib}/mystuff.py" is not a valid file name.

Or you can get downright parse errors etc. Sure there *are* cases where it 
could go unnoticed: if you're creating package content based on such a 
%define - using the python_sitelib again as a dumb example, rpm wouldn't 
complain about file created (and packaged) from this, you'd just get wrong 
contents (unexpanded macro name) in the file:

cat << EOF >> my.conf
%{python_sitelib}/mylib/
EOF

...but the potential for such silent errors has been there all the 
time: you just need to call a parametrized macro (knowingly or as a 
side-effect) somewhere in the spec and poof.

Oh and btw, technically there's nothing illegal or wrong with the 
construct "%{?!foo: %define foo bar}" itself. What's wrong is trying to 
*use* macro defined that way outside the %{} block where it was defined.

 	- Panu -




More information about the devel mailing list