Expanding macros which aren't handled by the rpm_macros context manager can yield stale data

[euanh]

The rpm_macros context manager adds and removes standard package macros such as %name, %version and %release, plus any extra macros passed in on the command line. It should be used whenever we call rpm.expandMacros, such as in the @expandmacros decorator.

Non-standard macros defined in specs, such as %commit, are not cleared by the context manager or by the RPM library and remain in a global environment. There seems to be no way to clear this environment or to ask the spec object which macros it defines. This means that if we load several specs which define %commit and then later expand the %commit macro, we will get the value set by the most recently loaded spec, which is not necessarily correct.

When adding the ability to use macros in links, we specifically decided to load the strings into the Spec object without expanding any macros in them, and then added the @expandmacros decorator to do this when the decorated function was called. Unfortunately, if another spec defining the macro is parsed in the meantime, its value of the macro will be used. To avoid this, we should expand macros in link strings when we load them, as we know that at that point we have just loaded the corresponding spec into the RPM library and we should have the right macro definitions. It is convenient to keep the @expandmacro decoration as well, as it makes building paths using macros such as %_sourcedir much neater.

In short, unless we are expanding macros which don't change such as %_sourcedir, or standard ones such as %version, we should expand them just after loading the Sp ec so we are sure we have the right values. One approach could be to reload the spec into RPM in the rpm_macros wrapper, to ensure the definitions are fresh. This would probably be slow.

[mseri]

A fix went in. I'll postpone further cleanups