Bug 226003 - Merge Review: libexif
Merge Review: libexif
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Schwendt
Fedora Package Reviews List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-31 14:21 EST by Nobody's working on this, feel free to take it
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-10 20:41:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
bugs.michael: fedora‑review+


Attachments (Terms of Use)

  None (edit)
Description Nobody's working on this, feel free to take it 2007-01-31 14:21:15 EST
Fedora Merge Review: libexif

http://cvs.fedora.redhat.com/viewcvs/devel/libexif/
Initial Owner: mclasen@redhat.com
Comment 1 Roozbeh Pournader 2007-02-04 13:12:12 EST
Taking for review.
Comment 2 Roozbeh Pournader 2007-02-04 14:30:34 EST
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.
Comment 3 Matthias Clasen 2007-02-04 22:08:00 EST
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.
Comment 4 Matthias Clasen 2007-02-04 22:21:53 EST
I also added a fix for multilib conflicts due to generated docs.
Comment 5 Roozbeh Pournader 2007-02-05 08:12:51 EST
I believe I can't finish this review, not understanding multilib issues well
enough. Leaving for someone else to take.
Comment 6 Michael Schwendt 2007-02-06 18:43:03 EST
> 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.
Comment 7 Michael Schwendt 2007-02-06 18:46:45 EST
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.)
Comment 8 Ville Skyttä 2007-02-06 19:01:07 EST
(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.
Comment 9 Matthias Clasen 2007-08-10 20:41:10 EDT
This review is done.

Note You need to log in before you can comment on or make changes to this bug.