On 3/7/25 8:41 AM, Panu Matilainen wrote:
On 3/6/25 5:16 PM, Michael Schroeder wrote:
On Thu, Mar 06, 2025 at 01:16:05PM +0100, Jean Delvare wrote:
I have another rpmbuild integration issue with "quilt setup". We call
rpmbuild -bp with --define "__tar $tmpdir/bin/tar". This is a wrapper
we use to collect information before we call the actual tar binary.
Since rpm 4.18, archives are handled by a new helper binary,
rpmuncompress. As I understand it, rpmuncompress ultimately calls the
real tar binary, found with rpmGetPath("%{__tar}", NULL). My problem is
that this now calls the system's tar, instead of our wrapper. This
prevents me from calling the information I need.
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.
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.
- Panu -
_______________________________________________
Rpm-maint mailing list
[email protected]
https://lists.rpm.org/mailman/listinfo/rpm-maint
