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(a)jcomserv.net> 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.