Packaging Committee Meeting Summary (2010-02-03)

[Nicolas Mailhot]

Le Jeu 4 février 2010 10:26, Till Maas a écrit :
> 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}

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)

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.

Some things are easy to take into account. This change is not, because it
depends on humans not making human mistakes (not like the define=>global
change that was 100% equivalent for humans). I don't see how the induced work
could even remotely be worth it. (remember, this is only about prettifying
summaries in srpms and koji no one but a tiny part of our user base will ever
look at).

If the objective is to make sure such macro call traces are eliminated from
summaries, and unless someone finds an actual case when someone needs to
display something looking macro calls in a summary, the correct and robust
solution is just to have rpmbuild zap those calls at srpm build time. But if
the issue is not worth the developer time to change rpm, it's certainly not
worth the time needed to fix it manually (and by fix I do not mean just a one
time sed run, I mean making sure this pattern is not reintroduced and
hand-holding all the packagers that will make new mistakes because the syntax
suddenly become more human-error-inducing).

-- 
Nicolas Mailhot