[Bug 246387] Review Request: libibcommon - OpenFabrics Alliance InfiniBand management common library

[bugzilla at redhat.com]

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

Summary: Review Request: libibcommon - OpenFabrics Alliance InfiniBand management common library


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





------- Additional Comments From tibbs at math.uh.edu  2007-07-04 15:48 EST -------
I talked with some other folks about this and the bottom line is that four of us
(Brian Pepple, Kevin Fenzi, Toshio Kuratomi and I) all agree that we have issues
with the intended method of maintenance of this package.  We have packages in
the distribution where the spec is maintained as part of the upstream source,
but with those packages the spec is actually pulled from Fedora into the
upstream source, which is the opposite direction from this package.

Ultimately, the following sentence from comment #2 is a deal-breaker for us:

The spec file is autogenerated from the actual code repo, so any changes to the
spec file that aren't done in the upstream repo would be lost.

Is it possible that there's a misunderstanding here?

As an act of good faith, let me go ahead and run through a full review so that
we can make progress in the event that the above issue is resolved.

rpmlint says:
W: libibcommon incoherent-version-in-changelog - 1.0.3-0.3.20070703git.fc8
  Your changelog entries need to be in the proper format, which includes the 
  version and release; see 
  http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs

W: libibcommon-devel no-documentation
W: libibcommon-static no-documentation
  These are OK.

I can't fetch the upstream source.  I don't even know how to fetch a tarball
from a git URL.  You will need to provide instructions for grabbing the source
from upstream; see http://fedoraproject.org/wiki/Packaging/SourceURL

Note that there are some who are firmly against ever running the autotools in a
spec; I happen to not be one of them, but that's really the kind of thing that
should be done by upstream as part of making the source snapshot.

It's not actually necessary to run ldconfig in the -devel package.

Nothing seems to own /usr/include/infiniband.  Actually, libibverbs-devel owns
it, but it's not in the dependency list.  See
http://fedoraproject.org/wiki/Packaging/Guidelines#FileAndDirectoryOwnership

Review:
X can't compare source files with upstream.
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (development, x86_64).
* package installs properly
* debuginfo package looks complete.
X rpmlint has one valid complaint (changelog format).
* final provides and requires are sane:
  libibcommon-1.0.3-0.3.20070703git.fc8.x86_64.rpm
   libibcommon.so.1()(64bit)
   libibcommon.so.1(IBCOMMON_1.0)(64bit)
   libibcommon = 1.0.3-0.3.20070703git.fc8
  =
   /sbin/ldconfig
   libibcommon.so.1()(64bit)

  libibcommon-devel-1.0.3-0.3.20070703git.fc8.x86_64.rpm
   libibcommon-devel = 1.0.3-0.3.20070703git.fc8
  =
?  /sbin/ldconfig
   libibcommon = 1.0.3-0.3.20070703git.fc8
   libibcommon.so.1()(64bit)

  libibcommon-static-1.0.3-0.3.20070703git.fc8.x86_64.rpm
   libibcommon-static = 1.0.3-0.3.20070703git.fc8
  =
   libibcommon = 1.0.3-0.3.20070703git.fc8

* %check is not present; not test suite upstream.
* shared libraries present; ldconfig is called as necessary in the main package 
   and the unversioned .so file is in the -devel subpackage.
X nothing owns /usr/lib/infiniband
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* scriptlets are OK (ldconfig)
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in the -devel subpackage.
* no pkgconfig files.
* static libraries are in the -static subpackage.
* no libtool .la files.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.