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. > > 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. Thanks, -- Jean Delvare SUSE L3 Support _______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
