[Bug 476475] Review Request: python-zope-filesystem - Python-Zope Libraries Base Filesystem
bugzilla at redhat.com
bugzilla at redhat.com
Wed Dec 17 23:54:22 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=476475
Kevin Kofler <kevin at tigcc.ticalc.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flag|fedora-review? |fedora-review+
--- Comment #6 from Kevin Kofler <kevin at tigcc.ticalc.org> 2008-12-17 18:54:21 EDT ---
Reviewing the updated specfile (same URL):
MUST Items:
+ rpmlint output OK (see comment #3)
+ named and versioned according to the Package Naming Guidelines
+ spec file name matches base package name
+ Packaging Guidelines:
+ License ZPLv2.1 OK
+ No patent problems
+ No emulator, no firmware, no binary-only or prebuilt components
+ Complies with the FHS (uses proper Python directories)
+ proper changelog, tags, BuildRoot, Requires (none needed, python(abi)
dependency autodetected), BuildRequires, Summary, Description
+ no non-UTF-8 characters
+ no relevant documentation which would need to be included
+ nothing to compile, so RPM_OPT_FLAGS, debuginfo, static libraries, .la
files, duplicated system libraries, rpaths, _smp_mflags don't apply
+ debuginfo package is properly disabled (package is only arch-specific
because of python_sitearch)
+ no configuration files, so %config guideline doesn't apply
+ no init scripts, so init script guideline doesn't apply
+ no executables, so no .desktop file present or needed
+ no timestamp-clobbering file commands
+ scriptlets are valid
+ not a web application, so web application guideline doesn't apply
+ no conflicts (assuming python-zope-interface gets changed to use this,
otherwise we have a file conflict, but that's planned already)
+ complies with all the legal guidelines
+ no license which would need including as %doc
+ spec file written in American English
+ spec file is legible
+ no upstream to compare source against ("source" is only a trivial __init__.py
file)
+ builds on at least one arch (F9 i386 live system)
+ no known non-working arches, so no ExcludeArch needed
+ all build dependencies listed as BuildRequires
+ no translations, so locale guidelines don't apply
+ no shared libraries, so need to call ldconfig
+ package not relocatable
+ ownership correct (owns package-specific directories, doesn't own directories
owned by another package)
+ no duplicate files in %files
+ permissions set properly (defattr used correctly)
+ %clean section present and correct
+ macros used where possible
+ no non-code content
+ no large documentation files, so no -doc package needed
+ no %doc files, so no possible issues with %doc files required at runtime
+ no header files or .so symlinks which would need a -devel package
+ no static libraries, so no -static package needed
+ no .pc files, so no Requires: pkgconfig needed
+ no .la files
+ no GUI programs (in fact, no executables at all), so no .desktop file needed
+ buildroot is deleted at the beginning of %install
+ all filenames are valid UTF-8
SHOULD Items:
? maybe we want to include a copy of the ZPLv2.1? But is it worth it for this
trivial package? Not a blocker in any case.
+ no translations for description and summary provided (no upstream)
* mock build not tested
* all architectures not tested, there's not much potentially arch-specific in
the package anyway
* no functionality test needed
+ scriptlets are sane
+ no subpackages, so "Usually, subpackages other than devel should require the
base package using a fully versioned dependency." is irrelevant
+ no .pc files, so "placement of .pc files" is irrelevant
+ no file dependencies
Nitpick: %if "%{python_sitearch}" != "%{python_sitelib}" could also be used in
%install to avoid redundantly installing the file twice. But it doesn't really
matter.
APPROVED
--
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 Fedora-package-review
mailing list