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=225856





--- Comment #13 from Zdenek Prikryl <zprik...@redhat.com>  2009-02-05 04:14:30 
EDT ---
(In reply to comment #12)
> Thank you for going on, rpmlint against latest CVS build (from http://
> cvs.fedoraproject.org/viewvc/devel/gpm/gpm.spec?revision=1.69)
> 
> > gpm.x86_64: W: shared-lib-calls-exit /usr/lib64/libgpm.so.2.1.0 
> > e...@glibc_2.2.5
> 
> Any ideas for this? That really looks strange to me - and I do not really
> have a clue what causes this. See also below at the bottom of this comment.

This is caused by exit() function. If something goes wrong, libgpm calls
exit(). This isn't standard library behaviour. Even in the source code there is
a comment that mentions this fact. But anyway, right now there isn't a easy way
how to get rid of exit() calls. I mean, if we want to remove calls, we'll have
to change an architecture of library's reporting stuff. So, IMO we can ignore
this warning.

> 
> > %__cc %{?_smp_mflags} -o inputattach %{SOURCE2}
>
> Well, we've lost $RPM_OPT_FLAGS. See build logs: %{?_smp_mflags} only causes
> -jX, not the rest of the flags $RPM_OPT_FLAGS would bring. So please re-add.

Right, re-added.

> Could you perform real integer comparisons rather half string comparisions?
> 
> -if [ "$1" = "0" ]; then
> +if [ $1 -eq 0 ]; then
> 
> -if [ "$1" -ge "1" ]; then
> +if [ $1 -ne 0 ]; then

I had a conversation about this and string comparison is safer than integer
comparison. So that's why I prefer this.

> 
> Following is suggested to not break rpm transaction if something goes wrong:
> 
> -/sbin/install-info %{_infodir}/gpm.info.gz --delete %{_infodir}/dir
> +/sbin/install-info %{_infodir}/gpm.info.gz --delete %{_infodir}/dir || :

IMO, if something goes wrong, user has to be notified.

I committed spec with corrections.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

_______________________________________________
Fedora-package-review mailing list
Fedora-package-review@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-package-review

Reply via email to