On 5/6/14, 4:35 AM, Simon Lukasik
wrote:
On
05/01/2014 08:31 PM, Shawn Wells wrote:
>To express
my subjective opinion I like the idea of the project to be
>renamed to "OpenSCAP Security Guide". But wanted to know
wider opinions
>from the community on the potential translation.
I think it's not necessary to rename the projects themselves.
However I am all for promoting the OpenSCAP "umbrella" and
cross linking the projects. Renaming the projects would be
very costly and confusing for existing users. The benefits
aren't worth it IMO.
In my opinion scap-security-guide should stay as is because
openscap-security-guide implies a tool lock-in which is not
the case.
Jan, thank you for starting this conversation! I'm _*very*_ much in
favor of a unified umbrella/naming.
As sgrubb pointed out, OpenSCAP has classically been the
interpreter. If
we rename SSG to "OpenSCAP Security Guide," the name creates an
impression the content would only work with OpenSCAP. For this
reason,
are you proposing we change the OpenSCAP interpreter as well?
e.g.:
OpenSCAP: A portfolio of open source SCAP utilities and content,
which
includes:
* OpenSCAP Workbench: Used for tailoring content
(formerally
scap-workbench)
* OpenSCAP Interpreter: A cross platform, open
source SCAP
interpreter)
* OpenSCAP Content: An open source project
delivering a
large body of SCAP content. Used as upstream for such profiles
as the
STIG and C2S
* OpenSCAP Anaconda Plugin: A project to integrate
SCAP
scanning into Linux provisioning
* OpenSCAP Spacewalk Plugin: A project to integrate
centralized SCAP scanning into the Spacewalk/Satellite system
management
software
I like this idea.
However, I am afraid we are not able to enforce openscap package
rename everywhere to ensure consistent look. OpenSCAP library is
spread across to many downstreams. That leads me to conclusion
that perhaps we don't need to rename the downstream packages.
Perhaps, we can just leverage this idea to better describe
ecosystem to newcomers.
Having a 90% solution is better than none; I see no harm if the
OpenSCAP library package remains an outlier. As Greg pointed out,
the impact of any change could be made over time (e.g. perhaps
RHEL7).
Today downstream already follows the openscap-* naming scheme, e.g.
from RHEL 6.5:
# yum search openscap
...
firstaidkit-plugin-openscap.noarch : OpenSCAP plugin for
FirstAidKit
openscap-devel.i686 : Development files for openscap
openscap-devel.x86_64 : Development files for openscap
openscap-engine-sce.x86_64 : Script Check Engine plug-in for
OpenSCAP
openscap-engine-sce-devel.x86_64 : Development files for
openscap-engine-sce
openscap-perl.x86_64 : Perl bindings for openscap
openscap-python.x86_64 : Python bindings for openscap
openscap-utils.x86_64 : Openscap utilities
openscap.i686 : Set of open source libraries enabling integration
of the SCAP line of standards
openscap.x86_64 : Set of open source libraries enabling
integration of the SCAP line of standards
openscap-content.x86_64 : SCAP content
openscap-content.noarch : SCAP content
openscap-extra-probes.x86_64 : SCAP probes
Formally changing "SCAP Workbench" to "OpenSCAP Workbench," or SSG
to "OpenSCAP Content" seems acceptable.
One catch is that RHEL already has a package "openscap-content."
Perhaps we could absorb the name? Or would this cause issues?