[Bug 798438] Review Request: uthash-devel - Hash table and linked list for C structures

bugzilla at redhat.com bugzilla at redhat.com
Tue Mar 13 12:21:18 UTC 2012


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=798438

--- Comment #7 from Michael Schwendt <mschwendt at gmail.com> 2012-03-13 08:21:15 EDT ---
* The License tag "BSD" is okay now.


* The empty %build section belongs _before_ %install not after it.


* The empty %clean section may be removed completely. It makes no sense to keep
it, since the default is sufficient.


* Closer reading of the %description reveals this unclear sentence:

| It is a development package without a source or binary package as
| there are only header files.

"without a source or binary package" - How is that meant to be understood? A
"source package" commonly is the src.rpm package. A "binary package" is the
build, no matter whether "noarch" or arch-specific.

Before that, the description already explains that it is a "C preprocessor
implementation". In case that needs further explanation, you could write:
"There is no shared library for uthash, just C header files."


* Several items mentioned in comment 2 are not okay yet. Would you mind
checking your own package against the
  https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
page? For example, here a few items that must be dealt with:

MUST: rpmlint must be run on the source rpm and all binary rpms the build
produces. The output should be posted in the review.

MUST: The package must be named according to the Package Naming Guidelines .

MUST: If (and only if) the source package includes the text of the license(s)
in its own file, then that file, containing the text of the license(s) for the
package must be included in %doc.

MUST: Permissions on files must be set properly. Executables should be set with
executable permissions, for example.
https://fedoraproject.org/wiki/Packaging/Guidelines#FilePermissions


* With regard to "MUST: Static libraries must be in a -static package",
strictly speaking, this header-only package (that doesn't build a shared
library) would need to adhere to the Static Library Packaging guidelines and
provide a virtual -static subpackage "Provides". In case of a security
vulnerability, for example, one would need to query for all packages that
BuildRequires uthash-static and rebuild them.
However, header-only packages are somewhat of a grey area and are not covered
by the guidelines yet. One would need to query for BuildRequires uthash-devel
instead, which could be a little bit confusing.

Hence my proposal is: Add an important note at the top of the spec file,
explaining that uthash-devel is a special header-only package, and any packages
that build with it may need special treatment for crucial fixes in uthash.


* With regard to the package naming guidelines and comment 2, it is still
confusing why you introduce the "uthash-dev" namespace for the documentation of
a package that is called uthash-devel. Do you disagree with the hint in comment
2? Once you would follow the licensing guidelines (one of the "MUST" items
above), you would introduce a second doc directory anyway. You'll see.

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



More information about the package-review mailing list