On Thu, Feb 04, 2010 at 10:26:05AM +0100, Till Maas wrote:
On Thu, Feb 04, 2010 at 09:20:12AM +0100, Kevin Kofler wrote:
Nicolas Mailhot wrote:
That would probably avoid the koji display problem but is sure to introduce packaging bugs. The macro call has been put in this particular place because experience shows that reduces human mistakes. It's never easy to do back and forths between two parts of the same file, but in this case they are compounded by the kind of syntax forced on us by the use of a macro. Everything needs to be cramed on a single line. Any syntax error and things fail without proper error messages (I've tried to add some debug output. I caused mock build to stop dead). You can not do as many calls as you want (like you can for %doc) or rpm will complain of multiple %posts or %files for the same subpackage (without telling you exactly which subpackage fails)
The choice that was made was to minimize human error risk at the expense of some prettiness in koji. I'd do the same choice today in a blink. We are severely limited what the tools can do, but trying to accomodate tools at all costs results in undue human burden and lots of bad packages. Humans have limits too.
Sorry, but the decision has been made, you have to put the macro where it belongs. Something which expands to scriptlets and %files sections needs to go where the scriptlets and %files sections belong, NOT in the Summary where it will be wrong in the SRPM. The problem is that it's not only within Koji that the unexpanded macros show up, but also in the shipped SRPMs!
Why can't the following be used? %{?_font_pkg:%_font_pkg -f %{fontconf}.conf AccanthisADFStd-*.otf}
That would be another option.
Since the macro is not really part of the Summary, there is no missing information if it does not expand.
Btw. the guidelines looks incomplete. This is the second sentence:
| Because SRPMs are built without the package's BuildRequires installed, | depending on macros defined outside of the spec file can easily lead to | this issue.
But there is no real explanation of "the issue", e.g. the problem that macros that are not really intended to build the packages description are shown unexpanded in the description.
Thanks. Added a few words about the end effect we're trying to avoid.
-Toshio