On 3/7/25 10:54 AM, Jean Delvare wrote:
Hi Panu,
On Fri, 7 Mar 2025 08:45:20 +0200, Panu Matilainen wrote:
On 3/7/25 8:41 AM, Panu Matilainen wrote:
On Thu, Mar 06, 2025 at 01:16:05PM +0100, Jean Delvare wrote:
This comes as a surprise to me, I would expect my __tar definition to
be honored by rpmuncompress the same way it was honored before that
helper binary was introduced. Is this a bug?
I can certainly see how that change breaks this kind of usage, but is
this kind of usage supported to begin with? I don't know.
Why not? rpmuncompress is an implementation detail, the end user
shouldn't be affected by that. So any macro which makes sense to
rpmbuild (and I would argue that %__tar, %__patch, %__unzip and the like
do qualify) should also be honored by rpmuncompress.
I meant the degree of which overriding arbitrary bits and pieces from
the command line is supported to begin with. Obviously *some*, otherwise
the option shouldn't be there at all. But also, somewhere in there
exists a line where we would have to say "not supported" even though a
thing happens to be exposed as a macro you technically can override from
the cli, because all manner of weird internals are exposed that way. The
command helper paths certainly seem on the "innocent" side of it all,
but they are also an "implementation detail".
It's basically just a question I need to ask myself whenever these kind
of things come up.
Fixing it would be tricky anyhow, we have no way to pass the entire
macro context to another program. And that's what we'd need to do - it's
not enough to pass just the macros rpmuncompress directly references,
because those macros could rely on something else defined this way.
And as it always happens, right after hitting send...
We could solve this by adding an export function for the macro context.
Then rpmbuild could dump the entire macro context into a temporary macro
file and pass that as --macros=/tmp/xxxx to all the relevant commands,
including at least rpmuncompress.
Sounds like a great idea. Considering that rpmuncompress makes explicit
use of rpm macros, I would definitely expect it to inherit the macro
context from its parent (rpmbuild), so that it resolves macros to the
same values rpmbuild itself would.
Yeah, there is a correctness issue there, whether it's a command line
override or not. Actually, just passing a custom --macros to rpmbuild
will have the same effect.
Created a ticket for this now:
https://github.com/rpm-software-management/rpm/issues/3643
Thanks for reporting!
- Panu -
Thanks,
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
