RPM Community Forums

Mailing List Message of <rpm-devel>

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c rpm/ macros.in

From: Anders F Björklund <afb@rpm5.org>
Date: Mon 20 Oct 2008 - 08:15:32 CEST
Message-Id: <2CDA6FF1-8E2E-48CB-A258-111836746E3F@rpm5.org>
Jeff Johnson wrote:

> Fussing with --fuzz opens up a world of pain and voids the warranty  
> of %patch macros.

Right, so that's why I left the default as "-1" (which translates to 2)
rather than changing the default to the stricter "0" as done elsewhere.

> If you want pain, try
>    #%patchN
> in spec files.

Yup, learned the hard way to comment my "%patchN" as "#patchN" instead.
Using %% would have worked too, I suppose, but wasn't what I was doing.

> I'm unable to convince myself that burying New Fangled Secret Sauce  
> Switches internally
> to the rpmbuild parser is in anyone's interest whatsoever.

I only added it to the rpmbuild parser for "completeness", should the
dying parser could ever be used. The main path is through the macro ?

> There certainly has been nothing stopping use of %{PATCHn} within % 
> prep (and any other
> spec file section, %patch was traditionally %prep-only) as
>    %{__patch} --whatever --bleeping --options --you --wish < %{PATCHn}

Right, and this is useful when e.g. doing a runtime sed on the patch...
Maybe editing specs would have been better than trusting a runtime  

> Contrast the aesthetics of that naked shell line with the Secret Sauce
>    %patchN --revetahw --gnipeelb --snoitpo --uoy --hsiw
> for a net gain of perhaps sizeof(" < %{PATCHn}") in the amount of  
> typing effort
> and a net loss (because hardly "standard" or "documented" within  
> rpmbuild) of
> portability and utility.
> But whatever ... if you want the gain of --fuzz, you can have the  
> pain too.

All that was added was a optional default parameter to %{__patch}. :-)
One could have just defined %__patch macro as "patch -F0" instead, but.

Received on Mon Oct 20 08:15:34 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.