Fedora Merge Review: libexif http://cvs.fedora.redhat.com/viewcvs/devel/libexif/ Initial Owner: mclasen
Taking for review.
First issues and suggestions, in random order: * Several patch files in CVS are not used. Please remove. * change BuildRoot to %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) * The resolved URL for Source0 (http://umn.dl.sourceforge.net/sourceforge/libexif/lixexif-0.6.13.tar.bz2) gives me a 404 HTTP error. * The AUTHORS files shipped in the RPM is empty. * Change the Requires line of -devel to %{name} = %{version}-%{release} * Devel package description says that there are also static packages. There are not. * Don't use %makeinstall. Use make DESTDIR=$RPM_BUILD_ROOT install. * Documents are installed into two different directories, /usr/share/doc/libexif (in libexif-devel) and /usr/share/doc/libexif-%{version} (in libexif). Make them one. * Make -devel require pkgconfig, as it includes *.pc files.
Mostly fixed in libexif-0.6.13-3.fc7, except for * The resolved URL for Source0 (http://umn.dl.sourceforge.net/sourceforge/libexif/lixexif-0.6.13.tar.bz2) gives me a 404 HTTP error. Can't give a working source url for sourceforge-hosted projects. * Documents are installed into two different directories, /usr/share/doc/libexif (in libexif-devel) and /usr/share/doc/libexif-%{version} (in libexif). Make them one. The api docs are now in /usr/share/doc/libexif-devel-0.6.13, which is quite common for -devel packages.
I also added a fix for multilib conflicts due to generated docs.
I believe I can't finish this review, not understanding multilib issues well enough. Leaving for someone else to take.
> Can't give a working source url for sourceforge-hosted projects. It used to be easier a few months ago. The generic URL is http://dl.sf.net/%{name}/%{name}-%{version}.tar.* http://download.sourceforge.net/%{name}/%{name}-%{version}.tar.* and used to point to a round-robin DNS mirroring system. However, nowadays the system refuses to work and includes a host which doesn't respond. As a work-around, one can still use a prefix for a known mirror, e.g. http://umn.dl.sf.net/libexif/libexif-0.6.13.tar.bz2 http://us.dl.sf.net/libexif/libexif-0.6.13.tar.bz2 http://osdn.dl.sf.net/libexif/libexif-0.6.13.tar.bz2 http://mesh.dl.sf.net/libexif/libexif-0.6.13.tar.bz2 and so on. * A different release of this library may need "BuildRequires: gettext" or else would build without message object files. This version doesn't, but the configure script searches for gettext.
APPROVED (Cannot verify whether %doc files in multi-lib installations can cause conflicts actually. In case such conflicts are common, perhaps the packaging committee should discuss that a bit.)
(In reply to comment #6) > http://dl.sf.net/%{name}/%{name}-%{version}.tar.* > http://download.sourceforge.net/%{name}/%{name}-%{version}.tar.* > > and used to point to a round-robin DNS mirroring system. However, > nowadays the system refuses to work and includes a host which > doesn't respond. Generic SF.net URLs like http://downloads.sourceforge.net/%{name}/... (note "downloads", not "download") have worked well for me lately.
This review is done.