When BuildArch is encountered during spec parse, rpm recurses the
parse, but this doesn't reset/reload the global configuration and macros
to match. So eg a "BuildArch: noarch" package gets built with a
dramatically different macros depending on whether "--target noarch"
was used or not, whereas people expect it to be the same - after all we
give zero indication that anything might be wrong when --target wasn't
specified.

Automatically detect and handle this condition in the rpmbuild tool:
if the spec parse architecture disagrees with our loaded configuration,
request a reparse with reloaded configuration for the matching target.
This ensures 'rpmbuild -bb noarch.spec' and 'rpmbuild -bb --target
noarch noarch.spec' run with the same exact configuration.
Doing this also fixes the situation where build-time macro expansion
of build scriptlets (for template bits and dynamically generated spec
parts) yields totally different (bogus) than in the initial spec parse.
This also goes for RPM_ARCH environment and similar.

Avoid --undefine for dependency generation test, it doesn't work.
--undefine with --target was always broken, now it's just more visible
since it automatically applies to BuildArch too. Fixing that is a
separate matter.

A more sophisticated fix could be having a stack of macro contexts that we
copy, push and pop as necessary. That ought to solve the undefine too.

Fixes: rpm-software-management#3049

When BuildArch is encountered during spec parse, rpm recurses the
parse, but this doesn't reset/reload the global configuration and macros
to match. So eg a "BuildArch: noarch" package gets built with a
dramatically different macros depending on whether "--target noarch"
was used or not, whereas people expect it to be the same - after all we
give zero indication that anything might be wrong when --target wasn't
specified.

Automatically detect and handle this condition in the rpmbuild tool:
if the spec parse architecture disagrees with our loaded configuration,
request a reparse with reloaded configuration for the matching target.
This ensures 'rpmbuild -bb noarch.spec' and 'rpmbuild -bb --target
noarch noarch.spec' run with the same exact configuration.
Doing this also fixes the situation where build-time macro expansion
of build scriptlets (for template bits and dynamically generated spec
parts) yields totally different (bogus) than in the initial spec parse.
This also goes for RPM_ARCH environment and similar.

Avoid --undefine for dependency generation test, it doesn't work.
--undefine with --target was always broken, now it's just more visible
since it automatically applies to BuildArch too. Fixing that is a
separate matter (rpm-software-management#3070).

A more sophisticated fix could be having a stack of macro contexts that we
copy, push and pop as necessary. That ought to solve the undefine too.

Fixes: rpm-software-management#3049

When BuildArch is encountered during spec parse, rpm recurses the
parse, but this doesn't reset/reload the global configuration and macros
to match. So eg a "BuildArch: noarch" package gets built with a
dramatically different macros depending on whether "--target noarch"
was used or not, whereas people expect it to be the same - after all we
give zero indication that anything might be wrong when --target wasn't
specified.

Automatically detect and handle this condition in the rpmbuild tool:
if the spec parse architecture disagrees with our loaded configuration,
request a reparse with reloaded configuration for the matching target.
This ensures 'rpmbuild -bb noarch.spec' and 'rpmbuild -bb --target
noarch noarch.spec' run with the same exact configuration.
Doing this also fixes the situation where build-time macro expansion
of build scriptlets (for template bits and dynamically generated spec
parts) yields totally different (bogus) than in the initial spec parse.
This also goes for RPM_ARCH environment and similar.

Avoid --undefine for dependency generation test, it doesn't work.
--undefine with --target was always broken, now it's just more visible
since it automatically applies to BuildArch too. Fixing that is a
separate matter (rpm-software-management#3070).

A more sophisticated fix could be having a stack of macro contexts that we
copy, push and pop as necessary. That ought to solve the undefine too.

Fixes: rpm-software-management#3049

When BuildArch is encountered during spec parse, rpm recurses the
parse, but this doesn't reset/reload the global configuration and macros
to match. So eg a "BuildArch: noarch" package gets built with a
dramatically different macros depending on whether "--target noarch"
was used or not, whereas people expect it to be the same - after all we
give zero indication that anything might be wrong when --target wasn't
specified.

Automatically detect and handle this condition in the rpmbuild tool:
if the spec parse architecture disagrees with our loaded configuration,
request a reparse with reloaded configuration for the matching target.
This ensures 'rpmbuild -bb noarch.spec' and 'rpmbuild -bb --target
noarch noarch.spec' run with the same exact configuration.
Doing this also fixes the situation where build-time macro expansion
of build scriptlets (for template bits and dynamically generated spec
parts) yields totally different (bogus) than in the initial spec parse.
This also goes for RPM_ARCH environment and similar.

Avoid --undefine for dependency generation test, it doesn't work.
--undefine with --target was always broken, now it's just more visible
since it automatically applies to BuildArch too. Fixing that is a
separate matter (rpm-software-management#3070).

A more sophisticated fix could be having a stack of macro contexts that we
copy, push and pop as necessary. That ought to solve the undefine too.

Fixes: rpm-software-management#3049

When BuildArch is encountered during spec parse, rpm recurses the
parse, but this doesn't reset/reload the global configuration and macros
to match. So eg a "BuildArch: noarch" package gets built with a
dramatically different macros depending on whether "--target noarch"
was used or not, whereas people expect it to be the same - after all we
give zero indication that anything might be wrong when --target wasn't
specified.

Automatically detect and handle this condition in the rpmbuild tool:
if the spec parse architecture disagrees with our loaded configuration,
request a reparse with reloaded configuration for the matching target.
This ensures 'rpmbuild -bb noarch.spec' and 'rpmbuild -bb --target
noarch noarch.spec' run with the same exact configuration.
Doing this also fixes the situation where build-time macro expansion
of build scriptlets (for template bits and dynamically generated spec
parts) yields totally different (bogus) than in the initial spec parse.
This also goes for RPM_ARCH environment and similar.

Avoid --undefine for dependency generation test, it doesn't work.
--undefine with --target was always broken, now it's just more visible
since it automatically applies to BuildArch too. Fixing that is a
separate matter (#3070).

A more sophisticated fix could be having a stack of macro contexts that we
copy, push and pop as necessary. That ought to solve the undefine too.

Fixes: #3049

When BuildArch is encountered during spec parse, rpm recurses the
parse, but this doesn't reset/reload the global configuration and macros
to match. So eg a "BuildArch: noarch" package gets built with a
dramatically different macros depending on whether "--target noarch"
was used or not, whereas people expect it to be the same - after all we
give zero indication that anything might be wrong when --target wasn't
specified.

Automatically detect and handle this condition in the rpmbuild tool:
if the spec parse architecture disagrees with our loaded configuration,
request a reparse with reloaded configuration for the matching target.
This ensures 'rpmbuild -bb noarch.spec' and 'rpmbuild -bb --target
noarch noarch.spec' run with the same exact configuration.
Doing this also fixes the situation where build-time macro expansion
of build scriptlets (for template bits and dynamically generated spec
parts) yields totally different (bogus) than in the initial spec parse.
This also goes for RPM_ARCH environment and similar.

Avoid --undefine for dependency generation test, it doesn't work.
--undefine with --target was always broken, now it's just more visible
since it automatically applies to BuildArch too. Fixing that is a
separate matter (rpm-software-management#3070).

A more sophisticated fix could be having a stack of macro contexts that we
copy, push and pop as necessary. That ought to solve the undefine too.

Fixes: rpm-software-management#3049
(cherry picked from commit 96467dc)

When BuildArch is encountered during spec parse, rpm recurses the
parse, but this doesn't reset/reload the global configuration and macros
to match. So eg a "BuildArch: noarch" package gets built with a
dramatically different macros depending on whether "--target noarch"
was used or not, whereas people expect it to be the same - after all we
give zero indication that anything might be wrong when --target wasn't
specified.

Automatically detect and handle this condition in the rpmbuild tool:
if the spec parse architecture disagrees with our loaded configuration,
request a reparse with reloaded configuration for the matching target.
This ensures 'rpmbuild -bb noarch.spec' and 'rpmbuild -bb --target
noarch noarch.spec' run with the same exact configuration.
Doing this also fixes the situation where build-time macro expansion
of build scriptlets (for template bits and dynamically generated spec
parts) yields totally different (bogus) than in the initial spec parse.
This also goes for RPM_ARCH environment and similar.

Avoid --undefine for dependency generation test, it doesn't work.
--undefine with --target was always broken, now it's just more visible
since it automatically applies to BuildArch too. Fixing that is a
separate matter (#3070).

A more sophisticated fix could be having a stack of macro contexts that we
copy, push and pop as necessary. That ought to solve the undefine too.

Fixes: #3049
(cherry picked from commit 96467dc)