Bug 683148 - Review Request: openscap - Set of open source libraries enabling integration of the SCAP line of standards
Summary: Review Request: openscap - Set of open source libraries enabling integration ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: Package Review
Version: 5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Miloslav Trmač
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 188273 682207
TreeView+ depends on / blocked
 
Reported: 2011-03-08 17:07 UTC by Peter Vrabec
Modified: 2011-03-13 18:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-13 18:51:35 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Peter Vrabec 2011-03-08 17:07:38 UTC
Spec URL: http://people.redhat.com/pvrabec/openscap/openscap.spec
SRPM URL: http://people.redhat.com/pvrabec/openscap/openscap-0.7.0-1.fc12.src.rpm

Description: 
OpenSCAP is a set of open source libraries providing an easier path
for integration of the SCAP line of standards. SCAP is a line of standards
managed by NIST with the goal of providing a standard language
for the expression of Computer Network Defense related information.

Comment 1 Miloslav Trmač 2011-03-09 16:29:20 UTC
Blockers:
* The main package should own /usr/share/openscap{,/schemas,xsl}

* openscap-devel should require pkgconfig:
  "rpm in EPEL5 and below does not automatically create dependencies for pkgconfig files. Packages containing pkgconfig(.pc) files must Requires: pkgconfig (for directory ownership and usability)."

* Unimplemented initscript commands: https://fedoraproject.org/wiki/Packaging:SysVInitScript#Required_Actions
  - (service oscap-scan stop) should return 0
  - (service oscap-scan {condrestart,try-restart,reload}) should return 0
  - (service oscap-scan restart) should start the scan
     - probably makes sense to make an exception here and not do it

* Consistent macro usage:
  use only one of $RPM_BUILD_ROOT and %{buildroot}

* All perl modules must include the versioned MODULE_COMPAT Requires:
  Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))

> openscap-devel.x86_64: W: spurious-executable-perm /usr/share/doc/openscap-devel-0.7.0/examples/oval_probes.py
> openscap-devel.x86_64: W: doc-file-dependency /usr/share/doc/openscap-devel-0.7.0/examples/oval_probes.py /usr/bin/env
Please drop the executable permission


Non-blockers:
* Is it really useful to include latex source files in openscap-devel?

* Consider using (make install ... INSTALL='install -p') to preserve timestamps

* There seems to be a test suite - consider running (make check) in %check

> openscap-python.x86_64: E: non-executable-script /usr/lib64/python2.7/site-packages/openscap_api.py 0644L /usr/bin/python
Drop the #!/usr/bin/python

> openscap-utils.x86_64: E: non-executable-script /usr/share/openscap/oscap-scan.cron 0644L /bin/sh
Fair enough, but perhaps this should be a documentation file instead


Other rpmlint output:
> openscap-content.x86_64: W: no-documentation
> openscap-perl.x86_64: W: no-documentation
> openscap-python.x86_64: W: no-documentation
Documentation is in other subpackages, good enough

> openscap-perl.x86_64: W: private-shared-object-provides /usr/lib64/perl5/_openscap_pm.so _openscap_pm.so()(64bit)
> openscap-python.x86_64: W: private-shared-object-provides /usr/lib64/python2.7/site-packages/_openscap_py.so _openscap_py.so()(64bit)
Can not fix this, per https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering adding filters would break rpm file coloring

> openscap-utils.x86_64: W: non-conffile-in-etc /etc/bash_completion.d/oscap
Makes sense as it is

> openscap-utils.x86_64: W: no-reload-entry /etc/rc.d/init.d/oscap-scan
Having this warning is OK, but "reload" should return 0 - see above

> openscap-utils.x86_64: E: subsys-not-used /etc/rc.d/init.d/oscap-scan
Wants us to use /var/lock/subsys, good as it is

> openscap-utils.x86_64: W: incoherent-init-script-name oscap-scan ('openscap-utils', 'openscap-utilsd')
Initscript should supposedly be named like the package - I think the curent naming makes sense.

Comment 3 Miloslav Trmač 2011-03-13 18:51:35 UTC
Thanks, approved.


Note You need to log in before you can comment on or make changes to this bug.