Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 226003 - Merge Review: libexif
Summary: Merge Review: libexif
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michael Schwendt
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-01-31 19:21 UTC by Nobody's working on this, feel free to take it
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-08-11 00:41:10 UTC
bugs.michael: fedora-review+


Attachments (Terms of Use)

Description Nobody's working on this, feel free to take it 2007-01-31 19:21:15 UTC
Fedora Merge Review: libexif

http://cvs.fedora.redhat.com/viewcvs/devel/libexif/
Initial Owner: mclasen@redhat.com

Comment 1 Roozbeh Pournader 2007-02-04 18:12:12 UTC
Taking for review.

Comment 2 Roozbeh Pournader 2007-02-04 19:30:34 UTC
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-05 03:08:00 UTC
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-05 03:21:53 UTC
I also added a fix for multilib conflicts due to generated docs.

Comment 5 Roozbeh Pournader 2007-02-05 13:12:51 UTC
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 23:43:03 UTC
> 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 23:46:45 UTC
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-07 00:01:07 UTC
(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-11 00:41:10 UTC
This review is done.


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