Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=458054 --- Comment #14 from Jon Ciesla <limb@xxxxxxxxxxxx> 2008-11-04 12:02:37 EDT --- (In reply to comment #13) > Updated versions: > > Spec URL: http://arm4.org/Downloads/0.8-0.5/arm4.spec > SRPM URL: http://arm4.org/Downloads/0.8-0.5/arm4-0.8-0.5.fc9.src.rpm > > I must say though, it's kind of annoying to hit an rpmlint update in the few > short hour between submission and review :) Fortunately that isn't THAT common. :) > Some comments on these reported errors though. First of all, despite the > assertion of rpmlint, there are many cases where this is a valid design choice, > such as when a common error handler is put in a library. In this case, it was > used in panic conditions only, and I still think that's valid. At this point, > the fix is largely cosmetic, although I will address this more completely for a > future release. > > Which brings me to the larger issue. Fixing this will always require an > architectural rethink. At the very least, it will require a change to the > library version number, potentially putting it out of sync with the upstream > version. Ultimately this isn't the responsibility of the packager, but of the > original developer, and as pointed out already the developer may just say deal > with it. Honestly, if I weren't also the upstream developer, I wouldn't have > changed anything. As it is, I'm fixing internal libraries that provide no > public API for problems that I don't think exist. > > I guess my point is that this warning should largely be ignored during reviews. > The dangers of not doing so are too great. > > OK, rant done, the new code removes these warnings. If you really feel that strongly about it, why not make that case in a bug against rpmlint? It's always being changed to adapt to different use cases. And remember, rpmlint silence is not a prerequisite for approval, especially where warnings are concerned, it's more there to encourage discussion, documentation, and to make sure that both packager and reviewer have a better idea what's really going on. > With regard to your comments on the practice review, I did use the checklist at > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines. I'll do a better job > of noting the pass/fail states next time. I'll do a couple of additional > reviews later this week when I get some of my work out of the way. Sounds good. One or two more, plus this package's approval, and we're in business. I'll post a formal review of this package soon. > Thanks! > Dave -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review