Packaging Committee Meeting Summary (2010-02-03)

Kevin Kofler kevin.kofler at
Fri Feb 5 23:14:22 UTC 2010

Nicolas Mailhot wrote:
> Le Jeu 4 février 2010 10:26, Till Maas a écrit :
>> Why can't the following be used?
>> %{?_font_pkg:%_font_pkg -f %{fontconf}.conf AccanthisADFStd-*.otf}
> In theory in can. In practice that will increase the number of human
> mistakes since it is not a human-friendly syntax. Again my #1 objective is
> not to be pretty but to have something that works user-side with the
> packagers we have. (I'd like to have pretty srpms too but I'll settle with
> error-free rpms any day)

This is ridiculous. How hard can it be to copy&paste this syntax? That said, 
I think moving the macro to where it belongs (along with the other 
scriptlets and file lists) is the better solution. Either way, our 
guidelines should be optimized for correctness, not laziness or 

By the way, the whole concept of this kind of macros has been frowned upon 
and FESCo already recommended that the MinGW packagers simply paste their 
debuginfo logic directly into the specfiles instead of using this kind of 
macros. I guess the same recommendation can be given to the font packagers.

> Anyway I've taken the time to explain why the current wording is ambiguous
> (I do not use macros in summaries, that rpm fails to see where the summary
> ends is no fault of mine). I've taken the time to explain my problem (I
> need something which is simple enough people do not spend their time
> adding and correcting bugs induced by quirky rpm syntax).  If the aim is
> not to find the best compromise for everyone, but to play the 'too late,
> it's been decided, just do it' game (though I respectfully point out no
> guideline is in effect before FESCO approval) I'll play the 'compliance
> with 2010 guidelines is planified after full-distro compliance with 2008
> guidelines is done' game.

You don't have to enforce this, we can assign any provenpackager to do so. 
For new packages, it should be part of the review checklist.

        Kevin Kofler

More information about the devel mailing list