[Rpm-maint] [rpm-software-management/rpm] Use full build template (#480)
Andreas Scherer
notifications at github.com
Fri Jul 27 18:11:47 UTC 2018
Thanks @n3npq for your comments. My considerations were indeed triggered by today's work on `debbuild`, which (a) didn't use `%___build_post` at all, and (b) would use the inspecific value **0** in all situations, even errors. After inspecting the PR for `debbuild`, I changed `debbuild`'s `macros.in` by extending its `%___build_template` to use `%___build_body` and `%___build_post` directly, instead of expanding and merging these snippets at the last possible moment when creating the script files.
As `debbuild`'s `macros.in` is only a small subset if `rpmbuild`'s, I thought that only the former had a "broken", i.e. prematurely aborted `%___build_template`. However, I found (a) that `rpmbuild`'s `macros.in` was originally created in 1999 with the same flaw/restriction/w.h.y., and (b) that it had several variants of the related macros for different scripts.
At first I only created issue #479 to draw attention to this situation, but then I came up with the initial changes that would be necessary for a possible improvement. The goal here is plain and simple: reduce the complexity and amount of code.
I am well aware of the idiosyncrasies of `rpmbuild`'s specfile parsing, having spent many happy hours trying to make `debbuild` follow them quite closely, at least for the purpose of my own packages. However, I am not quite sure if the diversity of `%setup` and `%patch` are really problematic here. By default, the string contents of the `sb` parameter seems to be shipped to the script file as is and gets executed by a shell. I may be totally wrong, but an extra `expandMacros` should not affect the validness of this string part. Admittedly, I have not yet begun to inspect the `@x ... @y` part of my request for help in detail (nor have I started to dig into the internal macro handling). This may lead to further progress, but I can't quite assess the chances for success right now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/480#issuecomment-408497670
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180727/ff83f624/attachment.html>
More information about the Rpm-maint
mailing list