Packaging Committee Meeting Summary (2010-02-03)

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100204/1c2baf86/attachment.bin