[Bug 225808] Merge Review: gmime

Wed Dec 31 13:57:28 UTC 2008

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=225808

--- Comment #2 from Debarshi Ray <debarshi.ray at gmail.com>  2008-12-31 08:57:26 EDT ---
MUST Items: 

xx - rpmlint is unclean on RPM
    + [rishi at ginger ~]$ rpmlint gmime
      gmime.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libgmime-2.0.so.2.2.21 /lib64/libgmodule-2.0.so.0
      gmime.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libgmime-2.0.so.2.2.21 /lib64/libdl.so.2
      gmime.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libgmime-2.0.so.2.2.21 /lib64/libgthread-2.0.so.0
      gmime.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libgmime-2.0.so.2.2.21 /lib64/librt.so.1
      gmime.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libgmime-2.0.so.2.2.21 /lib64/libnsl.so.1
      1 packages and 0 specfiles checked; 0 errors, 5 warnings.
      [rishi at ginger ~]$ rpmlint gmime-sharp
      gmime-sharp.x86_64: W: no-documentation
      gmime-sharp.x86_64: W: devel-file-in-non-devel-package
/usr/lib64/pkgconfig/gmime-sharp-2.4.pc
      gmime-sharp.x86_64: W: summary-not-capitalized mono bindings for gmime
gmime-sharp.x86_64: E: only-non-binary-in-usr-lib
      1 packages and 0 specfiles checked; 1 errors, 3 warnings.
      [rishi at ginger ~]$

OK - follows Naming Guidelines
OK - spec file is named as %{name}.spec

xx - package does not meet Packaging Guidelines
    + The '%ifarch s390 s390x ppc64' condition looks wrong because
      devel/mono.spec has
      'ExclusiveArch: %ix86 x86_64 ia64 armv4l sparc alpha s390 s390x ppc'.
      Since Mono is unavailable in ppc64 causing gmime-sharp to be excluded
      for that architecture, a bug should be filed blocking the ExcludeArch
      tracker for PPC64 (https://bugzilla.redhat.com/238953). The bug number
      should be documented in the Spec file as a comment.
    + The -sharp sub-package's summary should start with a capital letter.
    + Invoking autoreconf and friends from the Spec file has evoked strong
      reactions in the past. In this case it would be easy to rework Patch2 to
      apply against mono/Makefile.in instead of mono/Makefile.am and then use
      chrpath to remove the rpaths. Remember to replace
      'BuildRequires: automake libtool' with 'BuildRequires: chrpath'. See:
      https://fedoraproject.org/wiki/Packaging/Guidelines#Removing_Rpath
      It looks like the --disable-rpath switch does not work, neither could I
      manage to get rid of the rpaths by modifying libtool. But chrpath is
      better than using autoreconf.
    + Here is how the unused-direct-shlib-dependency can be removed:

https://fedoraproject.org/wiki/PackageMaintainers/Common_Rpmlint_Issues#unused-direct-shlib-dependency
    + Instead of using mv to rename the files in the %install stanza, would it
      not be better to pass '--program-prefix=%{name}-' to %configure? It is
      there for this purpose only. If you choose to use this switch, please
      don't pass transform='s,x,x' to 'make install' in the %install stanza.
    + gmime-sharp-2.4.pc should be packaged in a separate -sharp-devel
      sub-package. See:
      https://fedoraproject.org/wiki/Packaging/Mono#-devel_packages
    + Can gmime-2.2.3-use-pkg-config.patch be removed from CVS?

OK - license meets Licensing Guidelines

xx - License field does not meet actual license
    + While most of the source code is under LGPLv2+, the gmime-uudecode and
      gmime-uuencode binaries are obtained from GPLv2+ sources -- src/*.[ch].
      This is a multiple licensing scenario. See:

https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios
      Please change the value of the License field to "GPLv2+ and LGPLv2+" and
      document it in the Spec or the package.
    + examples/*-example.c are under GPLv2+. It appears to be a simple mistake
      and would be good to request upstream to put them at par with the rest of
      the files.
    + util/md5-utils.[ch] are in the public domain.

xx - upstream license file not included in %doc
    + Please include src/COPYING, containing the GPLv2 text, also.

OK - spec file uses American English
OK - spec file is legible
OK - sources match upstream sources
OK - package builds successfully
OK - ExcludeArch not needed
OK - build dependencies correctly listed
OK - no locales
OK - %post and %postun invoke ldconfig
OK - package is not relocatable

xx - file and directory ownership
    + The -devel sub-package should have 'Requires: gtk-doc' because it
      installs files in /usr/share/gtk-doc.
    + Although 'Requires: gtk-sharp2' will pull in mono-core, it is better to
      have an explicit 'Requires: mono-core' since the -sharp sub-package
      installs files in /usr/lib/mono.

OK - no duplicates in %file
OK - file permissions set properly
OK - %clean present
OK - macros used consistently
OK - contains code and permissable content
OK - -doc is not needed
OK - contents of %doc does not affect the runtime
OK - header files in -devel
OK - no static libraries

OK - -devel has *.pc file and requires pkgconfig
    + Although 'Requires: glib2-devel' will pull in pkgconfig, it is better
      to have an explicit 'Requires: pkgconfig' for the sake of readability.

OK - library files without suffix in -devel
OK - -devel requires base package
OK - no libtool archives
OK - %{name}.desktop file not needed
OK - does not own files or directories owned by other packages
OK - buildroot correctly prepped
OK - all file names valid UTF-8

SHOULD Items:

OK - upstream provides license text
xx - no translations for description and summary
OK - package builds in mock successfully
OK - package builds on all supported architectures
OK - package functions as expected
OK - scriptlets are sane
OK - subpackages other than -devel requires base package

xx - pkgconfig files in -devel
    + gmime-sharp-2.4.pc should be packaged in a separate -sharp-devel
      sub-package. See:
      https://fedoraproject.org/wiki/Packaging/Mono#-devel_packages

OK - no file dependencies

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.