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 oron@actcom.co.il 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).
package-review@lists.fedoraproject.org