Hello Federico,
what you say is not entirely correct - the PR introduces a concept of
canonical addon names and its aliases, although tests assume that the
canonical name is com_redhat_oscap (that's probably not optimal). The
common.py file contains definitions of what are the canonical names and
aliases, and it also has a toggle whether to trigger the warning or not.
The motivation is straightforward - we don't want RHEL customers to use
Fedora references in their kickstarts, so we plan to remove the Fedora
addon name in favor of the RHEL one. Adding a new addon name is easy,
it's just about changing the corresponding line in the common.py module
at package-time, so you can add Oracle addon name as well if you wish or
you can turn those warnings off with minimal effort.
If you would like more robust support for naming or for general addon
configuration, we will be happy to review any PRs on that matter.
HTH,
Matej
On 20. 01. 22 1:35, Federico Ramírez wrote:
Hi Matěj!
I was tasked with evaluating if we need to/should add an oracle
specific name for the oscap-anaconda-addon.
After taking a look at the upstream PR 159
<https://github.com/OpenSCAP/oscap-anaconda-addon/pull/159> and more
specifically at the 2c3f9e22
<https://github.com/OpenSCAP/oscap-anaconda-addon/pull/159/commits/2c3f9e2233d361ba8d0992b2b39128865687fc11>
commit, it is clear to me that both currently available names
(org_fedora_oscap and com_redhat_oscap) are valid and can be used.
However the same commit adds a code snippet which triggers a warning
if a name different than the redhat one is used.
This makes it a bit confusing to me regarding the purpose of this
changes (adding a new addon name and deprecating the old one).
Would you be kind enough to share the reason behind this changes?
Thank you in advance
- Federico
_______________________________________________
Open-scap-list mailing list
Open-scap-list@redhat.com
https://listman.redhat.com/mailman/listinfo/open-scap-list
