Re: Packaging Committee Meeting Summary (2010-02-03)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!

        Kevin Kofler

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux