Bug 222043

Summary: Review Request: gnomescan - Gnome Scanner Utility
Product: [Fedora] Fedora Reporter: Deji Akingunola <dakingun>
Component: Package ReviewAssignee: Parag AN(पराग) <panemade>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: maxx
Target Milestone: ---Flags: kevin: fedora-cvs+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-13 18:06:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 163779    

Description Deji Akingunola 2007-01-09 19:24:06 UTC
Spec URL: ftp://czar.eas.yorku.ca/pub/gnomescan/gnomescan.spec
SRPM URL: ftp://czar.eas.yorku.ca/pub/gnomescan/gnomescan-0.4.0.2-1.src.rpm
Description: Gnome Scan aim to provide a sane scan infrastructure. Flegita provide
app and plugin on top of Gnome Scan for the desktop

Comment 1 Mads Villadsen 2007-01-09 22:33:01 UTC
I am not an official reviewer, so consider this a pre-review.

Builds in mock on i386 fedora core 6. Installs and runs - however I haven't got
a scanner, so I cannot test functionality.

rpmlint produces one error:
W: gnomescan-devel no-documentation

Which I suppose is fine, since the documentation belongs in the main package and
not in the devel package.

Package and spec file are correctly named
Language and license are fine.
find_lang is correctly used for locales.
ldconfig is correctly called in %post and %postun
Packages correctly own directories.
Correctly handles pkgconfig files.
Header files are in devel package.
Includes a .desktop file that is correctly installed.

What I am unsure about is this. It seems to me that this includes both gnomescan
(flegita - the actual scanning application) and libgnomescan. Should the two be
packaged separately?


Comment 2 Deji Akingunola 2007-01-09 23:23:08 UTC
(In reply to comment #1)
> I am not an official reviewer, so consider this a pre-review.

Thanks for looking at it.

> 
> What I am unsure about is this. It seems to me that this includes both gnomescan
> (flegita - the actual scanning application) and libgnomescan. Should the two be
> packaged separately?
> 
I believe it's okay as is, seems like flegita is sort of a codename or nickname,
and people who want to use the libs part can make use of the -devel subpackage.


Comment 3 Parag AN(पराग) 2007-01-10 05:33:04 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > I am not an official reviewer, so consider this a pre-review.
> 
> Thanks for looking at it.
> 
> > 
> > What I am unsure about is this. It seems to me that this includes both gnomescan
> > (flegita - the actual scanning application) and libgnomescan. Should the two be
> > packaged separately?

 I don' think we need both packaged separately.
> > 
> I believe it's okay as is, seems like flegita is sort of a codename or nickname,
> and people who want to use the libs part can make use of the -devel subpackage.
> 

However, I found that you don't need pkgconfig as BR for main package.
Also, do we really need libtool as BR and all other make LIBTOOL? I removed them
and did mock test and it went fine.
Can you check that with testing application??
 

Comment 4 Parag AN(पराग) 2007-01-10 05:45:52 UTC
Also i found you have option to create a separate package for gimp-plugin that
will contains single file in its installation.

Comment 5 Deji Akingunola 2007-01-10 14:08:49 UTC
(In reply to comment #3)

> 
> However, I found that you don't need pkgconfig as BR for main package.
Maybe not explicitly (probably some other dependencies pulled it in inside mock
for you), if you check the configure log you'll see that it checks for the
presence of pkgconfig, so its needed  for building.

> Also, do we really need libtool as BR and all other make LIBTOOL? I removed them
> and did mock test and it went fine.
Did you run rpmlint on the resulting binary? If you did, you will have found out
it has some rpath issues caused by using the libtool script bundled with the
package. That's the reason for the libtool as BR and all other make LIBTOOL.
(See
http://fedoraproject.org/wiki/Extras/Schedule/RpathCheckBuildsys?highlight=%28rpath%29)

As for your other comment on separate package for gimp-plugin, I don't think its
necessary just for a single file. Or is there some technical reason(s) for it to
be a separate package?

> Can you check that with testing application??
>  



Comment 6 Mads Villadsen 2007-01-10 17:56:26 UTC
My argument for maybe packaging libgnomescan separately is that if someone
produces another scanning application, and depends on gnomescan-devel we
suddenly have two different scanning applications installed, since
gnomescan-devel depends on gnomescan.

It is probably a minor detail at this, and is all depends on how you expect
libgnomescan to be used by other applications.

Comment 7 Parag AN(पराग) 2007-01-11 07:25:19 UTC
Review:
+ package builds in mock (development i386).
+ rpmlint is silent for SRPM and RPMS.
+ source files match upstream.
7c481bb5ce112ebf5889bc4cd63f5836  gnomescan-0.4.0.2.tar.gz
+ package meets naming and packaging guidelines.
+ specfile is properly named, is cleanly written
+ Spec file is written in American English.
+ Spec file is legible.
+ dist tag is present.
+ build root is correct.
+ license is open source-compatible.  License text included in package.
+ %doc is small; no -doc subpackage required.
+ %doc does not affect runtime.
+ BuildRequires are proper.
+ %clean is present.
+ package installed properly.
+ Macro use appears rather consistent.
+ Package contains code Not contents.
+ no static libraries present.
+ no gnomescan.pc and gnomescanui.pc files present.
+ -devel subpackage exists
+ included
  %post -p /sbin/ldconfig
  %postun -p /sbin/ldconfig
+ no .la files.
+ translations are available
+ Dose owns the directories it creates.
+ no duplicates in %files.
+ no scriptlets used.
+ Desktop files are handled correctly in spec.
+ file permissions are appropriate.
+ gui app.
APPROVED.


Comment 8 Deji Akingunola 2007-10-30 03:10:33 UTC
Package Rename CVS Request
=======================
Old name: gnomescan
New name: gnome-scan
Short Description: Gnome solution for scanning in the desktop on top of libsane
Owners: deji
Branches: F-7 F-8 devel
InitialCC:
Cvsextras Commits: yes

Comment 9 Kevin Fenzi 2007-10-30 16:38:57 UTC
I have created the new gnome-scan package. 

Please follow the end of life procedure for the gnomescan package:
http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife

Also, make sure the new package has the right Obsoletes/Provides:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-3cfc1ea19d28975faad9d56f70a6ae55661d3c3d