Bug 226003 - Merge Review: libexif
Summary: Merge Review: libexif
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Michael Schwendt
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Keywords:
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:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-11 00:41:10 UTC
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)

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.