Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=894338
--- Comment #19 from Michael Schwendt <mschwendt(a)gmail.com> ---
Hopefully this comment catches all issues:
https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
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.[4
MUST: The License field in the package spec file must match the actual license.
[3]
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
A complicated %prep section makes access to local %doc files more complicated,
btw.
[x]: License field in the package spec file matches the actual
license.
Note: Checking patched sources after %prep for licenses. Licenses found:
"GPL (v3 or later)", "Unknown or generated". 2 files have
unknown
license. Detailed output of licensecheck in
/tmp/894338-libdistorm3/licensecheck.txt
License: GPLv3
GPLv3+ actually.
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#.22or_later_...
[x]: %build honors applicable compiler flags or justifies otherwise.
It doesn't.
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at
the
beginning of %install.
Since %install automatically empties %buildroot, there is no need to "rm -fr
%{buildroot}%{_libdir}" either.
[x]: Package complies to the Packaging Guidelines
Not yet.
Summary: diStorm
This is a very bad summary. The summary should be a short and concise
description of the package.
https://fedoraproject.org/wiki/Packaging/Guidelines#summary
[x]: Fully versioned dependency in subpackages, if present.
https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package
[x]: Package is named according to the Package Naming Guidelines.
Debatable. There is nothing that mandates adding the "lib" prefix or appending
the "3". Upstream name is just "distorm". OpenSUSE have packaged it
differently, just for reference:
http://rpmfind.net/linux/rpm2html/search.php?query=distorm
[x]: Package does not generate any conflict.
It bears a risk though to install a very generic file name, such "mnemonics.h",
directly into /usr/include instead of placing files like that in a subdir.
$ rpmls -p libdistorm3-devel-3.3-1.fc19.x86_64.rpm
-rw-r--r-- /usr/include/distorm.h
-rw-r--r-- /usr/include/mnemonics.h
[x]: Final provides and requires are sane (rpm -q --provides and rpm
-q
--requires).
Not yet. There still is no SONAME:
libdistorm.x86_64: W: no-soname /usr/lib64/libdistorm3.so.3.3
And what the spec file tries to do about that in the %install section doesn't
make sense and doesn't result in sane RPM dependencies either.
[x]: Package functions as described.
Dubious. Without a libdistorm3.so it's somewhat inconvenient to compile/link
with this library. Has it been tested?
[!]: Description and summary sections in the package spec file
contains
translations for supported Non-English languages, if available.
This '!' seems to be fedora-review's warning that the summary is not English
language, but just the name of this software.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=SRNisQpGZB&a=cc_unsubscribe