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.
We could intercept calls to rpmuncompress, however doing so would
require that we duplicate a lot of the logic already present in
rpmuncompress, so I'd rather avoid it if possible.
A somewhat related question would be: Should rpmuncompress support a
"--define" option?
I don't know. One could argue that since it reads macros it should
support all the macro-related options rpm/rpmbuild takes, including
--define and --macros and all. All that seems kinda out of place for
such a simple tool, but this simple tool does end up reading all of the
macro configuration and ... this also points out the fact that if a tool
used by rpmuncompress was defined in a platform config instead of main
macros, we'd get the wrong value here.
So this does seem to point out a larger bug there.
I guess we should split the macro options out to a separate popt table
that can then be selectively included from these tools without dragging
in all the goo that is now in rpmcliAllPoptTable.
- Panu -
Cheers,
Michael.
_______________________________________________
Rpm-maint mailing list
[email protected]
https://lists.rpm.org/mailman/listinfo/rpm-maint
