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. I think SRPMs should be worried about but you can certainly write a draft to remove or modify the buildtime SRPM macros guideline on that basis and the full FPC will vote on it. > > 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). > Hopefully the wording I've added at till's prompting will clarify that your usage is running afoul of the Guideline. Writing a draft to ask FPC to consider SRPMs of lesser importance than binary rpms and allow this when it makes the life of the packager easier to ignore the problem is still an option though. > > 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) > This was Kevin Kofler's statement, rather than the FPC (or any FPC members). You're welcome to bring it up and we can discuss it. However, I think this is a case that does fall under what we want to fix by this Guideline. You are correct that FESCo also has to approve the change and you are welcome to petition them with your argument as well. I do think that FPC has been delegated the authority in this area by FESCo though. > I'll play the 'compliance with 2010 guidelines is > planified after full-distro compliance with 2008 guidelines is done' game. > This part is childish. Although, if you want to use your provenpackager status to help find and fix low hanging fruit in those other packages that would be grat. > 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). > Mentioned up above that you can have the relavance of SRPMs questioned but there's another thing in here that should be addressed. It is true that humans make mistakes. But it is a packagers job to overcome those difficulties and package correctly. And it's a reviewers job to catch mistakes that a packager makes. We definitely should try to make the Guidelines as easy to apply as possible to avoid places where human error can occur but in the end we're responsible for creating correct packages whether the job is easy or hard. -Toshio
pgpJ8tuENVANL.pgp
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
