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