Bug 222043
Summary: | Review Request: gnomescan - Gnome Scanner Utility | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Deji Akingunola <dakingun> |
Component: | Package Review | Assignee: | Parag AN(पराग) <panemade> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | 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
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? (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. (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?? Also i found you have option to create a separate package for gimp-plugin that will contains single file in its installation. (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?? > 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. 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. 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 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 |