[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Heads-up: %define vs %global in specs



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 -


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]