[Bug 455555] Review Request: libhocr - A Hebrew optical character recognition library

[Red Hat Bugzilla]

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

--- Comment #6 from Oron Peled   2008-08-03 06:08:23 EDT ---
(In reply to comment #5)
> Well, for 0.10.13-1:

First, thanks for the excellent and detailed comments.
Since I'm working with upstream about some other small
issues, I'm merging the fixes and hope to upload an updated
package within a day or two.

A short checklist:
> Explicit library dependency
>
> On main package:
> Requires:       fftw, hspell

fftw - removed (yes it should be delegated to RPM)
hspell - move to hocr-gtk subpackage. This package
         uses gtktextbuffer (python bindings) which uses
         gtkspell which test at *runtime* for backend spellcheckers.
         Added a comment about that in the .spec file
> On -gtk subpackage:
> Requires:       gtk2

fixed.
> ** Requires
> Requires for -devel subpackage
> Every package which ships pkgconfig .pc files must have
> "Requires: pkgconfig"

Fixed. I didn't check .pc files at all. Looks like I should write
a small script to test these things (supplement rpmlint...)
> Also please pkgconfig files themselfs to check dependencies for
> -devel subpackage
>
> A. %_libdir/pkgconfig/libhocr-gtk.pc contains:
>
> Requires: gtk+-2.0

Fixed.
>     This means that libhocr-devel subpackage must have "Requires: gtk2-devel"
>
>  B. %_libdir/pkgconfig/libhocr.pc contains:
> Libs: -lhocr  -lhspell -lz  -ltiff -lm
>     This means that libhocr-devel must have 
>     "Requires: hspell-devel zlib-devel libtiff-devel" (because of
>     -lhspell -lz -ltiff)
>     However all these 3 linkage seem unneeded, because none of the
>     header files in libhocr-devel needs header files from 
>     fftw-devel, hspell-devel, libtiff-devel.
>     I guess "@ld_hspell@ @ld_tiff@" in libhocr.pc.in should be removed.

Their inclusion in the .pc file is correct since they are used
by the applications, either explicitly (tiffio.h and fftw3.h) or
implicitly (hspell via gtkspell). However, I'll have to digg deeper
to make sure *which* subpackage requires *what* (TODO)
> Requires for -gtk subpackage
> Please recheck the dependency for -gtk subpackage.
> For example, /usr/bin/hocr-gtk contains
> 28  import pygtk
> 29  pygtk.require('2.0')
> This means that libhocr-gtk must have "Requires: pygtk2".

Fixed.
> Timestamps
> To keep timestamps on installed files, please consider to use
>
> make install \
>         INSTALL="install -p" \
>         DESTDIR=%{buildroot}            \
> .....
> This method usually works for based Makefiles based on recent
> autotools

Hmmm... first time I see this consideration. It seems logical
but are these any guideline about it?

If it's a general problem maybe I can use your method as a solution
for this package, but it seems better to fix the AC_PROG_INSTALL
macro upstream (if they accept the same logic).
> Desktop files
> Category "X-Fedora" is deprecated and should be removed.

Done. I must have got its addition from some obsolete guide
somewhere but I cannot find any reference to it now, nevermind.
> %doc %_mandir
> Files under %_mandir are automatically marked under %doc

Removed the %doc.
> Directory ownership issue
> Please make it sure that all directories created when installing a
> rpm are correctly created by the rpm
> For example, %_datadir/hocr-gtk is not owned by any packages.

Fixed. Will recheck other ownerships as well.
> %files entry on -python subpackage
> On i386/ppc %{python_sitelib} and %{python_sitearch} are the same,
> so on these archs %files entries are duplicate as:
>
> 1131  warning: File listed twice: /usr/lib/python2.5/site-packages/_hocr.so
>   1132  warning: File listed twice: /usr/lib/python2.5/site-packages/hocr.py
>   1133  warning: File listed twice: /usr/lib/python2.5/site-packages/hocr.pyc
>   1134  warning: File listed twice: /usr/lib/python2.5/site-packages/hocr.pyo
> Writing %files entry a bit more verbosely can resolve this issue.

TODO. I need to check it again.
> 64 bits issue
> libhocr{-gtk}.pc.in contains:
>  2  exec_prefix=${prefix}
>  3  libdir=${exec_prefix}/lib
> So libdir is expanded as /usr/lib even on 64 bits archs, but this is wrong
> as on 64 bits archs libdir must be expanded as /usr/lib64.
> libdir=@libdir@ is correct.

Fixed (changed all assignments to use @...@ so we won't have wrong
assumptions in general and respect ./configure selections even in
non-rpm builds -- e.g: ./configure --prefix=/opt/kuku --includedir=/foobar
Sent upstream.

Updated packages+specs - ASAP (a day or two).