No, we'll cherry-pick obvious fixes when doing the next release.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2078687995
You are receiving this because you are subscribed to this thread.
Message ID:
Is there anything I need to do to initiate a backport to 4.19.x?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2076977118
You are receiving this because you are subscribed to this thread.
Message ID:
Oh and thanks for reporting! Like the testcase shows, we *kinda* knew about
this all along but had forgotten, and who knows how long more this might've
lurked along :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3056#issuecom
Closed #3056 as completed via #3059.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3056#event-12588517986
You are receiving this because you are subscribed to this thread.
Message ID:
___
R
It's a bug alright. I actually just stumbled on that code a couple of days ago
thinking this doesn't look right. It isn't.
It's not just multiple identical options, it's any local macro multiply
defined, issue being that freeArgs() only ever pops once. Easily reproduced
with eg
> rpm --define
Saner handling of multiple identical options would be nice, but even without
that, the described behavior is wrong. Agreed?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2072404151
You are receiving this because you
Yes, it's because the engine pushes the macro with each option but only pops it
once.
I guess we could modify freeArgs that it pops until the level is clear, or we
could change setupArgs so that it pushes just once.
But see also https://github.com/rpm-software-management/rpm/pull/2449 that asks