Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

--undefine doesn't work with --target #3070

Open
pmatilai opened this issue Apr 30, 2024 · 0 comments
Open

--undefine doesn't work with --target #3070

pmatilai opened this issue Apr 30, 2024 · 0 comments
Labels
bug

Comments

@pmatilai
Copy link
Member

--target causes the entire rpm configuration to be reloaded from scratch, and since --undefine operates on the init macro context at program startup, the rpmPopMacro()'s it does get lost in the reload. Filing this as "documentation" for the issue: if nothing else, it's inconsistent behavior.

Of course what's --undefine'd may get defined by a thousand other means too, it's just not a realiable way to do stuff in rpm.
@pmatilai pmatilai added the bug label Apr 30, 2024
pmatilai added a commit to pmatilai/rpm that referenced this issue Apr 30, 2024
@pmatilai
Automatically reload rpm configuration on mismatching BuildArch
c0504d9 
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
@pmatilai pmatilai mentioned this issue Apr 30, 2024
Merged
pmatilai added a commit to pmatilai/rpm that referenced this issue Apr 30, 2024
@pmatilai
Automatically reload rpm configuration on mismatching BuildArch
d09c5e9 
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
pmatilai added a commit to pmatilai/rpm that referenced this issue Apr 30, 2024
@pmatilai
Automatically reload rpm configuration on mismatching BuildArch
a5ea8c6 
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
pmatilai added a commit that referenced this issue May 6, 2024
@pmatilai
Automatically reload rpm configuration on mismatching BuildArch
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
dmnks pushed a commit to dmnks/rpm that referenced this issue May 17, 2024
@pmatilai @dmnks
Automatically reload rpm configuration on mismatching BuildArch
9b77288 
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)
dmnks pushed a commit that referenced this issue May 17, 2024
@pmatilai @dmnks
Automatically reload rpm configuration on mismatching BuildArch
14a0f0e 
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
RPM
Status: Backlog
Milestone
No milestone
Development

No branches or pull requests
1 participant
@pmatilai