Convert %prep into a regular build scriptlet
#2730
Conversation
This is just in preparation for exposing the handle in some APIs. No functional changes.
Just preparing to export in the next steps. No functional changes.
Add rpmPushMacroAux() function which allows registering auxiliary macros implemented in C and some required helper facilities: export the types, rpmMacroBufAppend*() and rpmMacroBufErr() functions, and finally add rpmMacroEntryPriv() to let macro retrieve their private data. And that's all folks.
This stupid syntax is the thing preventing %prep from becoming a normal script, and that in turn blocks so many things now that this has got to go. Considering how widely used this syntax is, this is a disruptive and abrupt change - we only started warning on %patchN in 4.18. So lets at least print out a legible error message with suggestions how to fix for now, even if it requires specifically checking for the obsolete syntax.
Now that we can, implement %setup and %patch as auxiliary macros that are defined only during %prep parsing. And voila, %prep is no longer special at all. Not much anyhow. Notably rpmspec --parse now emits %build where it belongs. The error message on %patchN is now very much an ugly hack, but at least it's something we can drop one sunny day. Fixes: rpm-software-management#2205
|
Technically, it'd still be possible to convert %patchN to %patch N, we'd just need to do it in specExpand() or other such place that has no clue about the current section. The risk of doing so seems quite minimal, but I'd just rather not. OTOH if axing support for %patchN turns out to be too controversial, we do have a plan B that doesn't require reverting this change and everything built on top of it. |
|
Looks actually quite nice and surprisingly straight forward. I wonder if we should do an announcement if we really want to drop %patchN so distributions have a bit more time to prepare. |
|
Yeah, after all the years of refactoring the final piece doesn't actually look like much 馃槅 We're already issuing deprecation warnings from 4.18 and 4.19, so when 4.20 lands in the first distros sometime next year it wont come out of the great big blue, but sure, banging some drums (more loudly) would be appropriate. |
|
So... if we're going to do this then lets just get on with it, because this is blocking or at least affecting so many other developments at this point. Like noted, if this turns out to be an utter PR disaster (in the other meaning of PR), it'll still be possible to add a different kind of hack to restore %patchN for one release more. |
dmnks
changed the title
%prep into a regular build scriptlet
This is a fun little series. Details in the commit messages, but briefly:
Fixes: #2205