Packaging Committee Meeting Summary (2010-02-03)

[Till Maas]

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}

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.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100204/5640850d/attachment.bin