Le jeudi 04 février 2010 à 11:16 -0500, Toshio Kuratomi a écrit :
> On Thu, Feb 04, 2010 at 11:49:46AM +0100, Nicolas Mailhot wrote:
> >
> >
> > 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)
> >
> Your priorities do not match with a good deal of the packaging community
> here. #1 priority should be to produce correct packages. Making doing that
> easy is likely in the running for #2, though.
>
> In this case, we have something that affects the packages that end users see
> so that takes precedence over making it easy for humans to do what is right.
> We can make it as easy as possible for the right thing to be done but
> actually doing the wrong thing and thinking it's okay is not.
>
> Your argument that the SRPM is only seen by a tiny fraction of our endusers
> and therefore we shouldn't worry about doing the right thing when it only
> affects SRPMS is a valid question.
No, my argument is that the problem this tries to protect against is
purely cosmetic, and is cosmetic in an area which has little practical
importance. That makes it very low in my priority scale. Nevertheless I
would support the fix anyway if it was safe. But it is not safe, it's
trading a problem which has no real practical consequences, for problems
that do have practical consequences.
It's too easy to say packagers just have to do better, packager time is
not limitless, it's a precious resource people are asking to squander
just because they can here. The day I have three candidates to package
each font the design team asks for I'll support this kind of nitpicking,
but in the meanwhile this kind of "just do it, packagers have to bear
the burden of working around rpm limits at any cost, even for cosmetic
issues" is not practical at all.
I've already written where efforts could be best allocated if this
"problem" was a priority (actually fixing rpmbuild so no manual
labour-intensive workarounds are required). I seriously question it is
worth it short term even with the "fix the actual rpmbuild bug"
approach. But the manual approach is insane (if someone has this kind of
manpower available I have a long long list of packages badly needing
fixing not just for cosmetic reasons, and fonts badly needing packaging)
--
Nicolas Mailhot
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
