Address incompatible profiles and software selections.

[matejak]

This change introduces a mechanism that allows to vet packages marked for removal.
Such package can now have a record in the ESSENTIAL_PACKAGES dict (yuck, but it works), that define whether the package is essential => can't be removed based on the environment and groups selected in the Software Selection Anaconda spoke.
In RHEL8, one can't just remove e.g. xorg-common, as the system will even refuse to install.

In case when one first selects the profile and then changes the Software Selection to an incompatible setting, the Selection spoke will raise an error, as it already tries to apply the blacklist with its environment/groups.

How have I tested this change:

1. Select e.g. the RHEL8 CIS profile with e.g. minimal install. The Security Policy spoke should inform user in an ordinary fashion that xorg is going to be excluded.
2. Change the software selection to Workstation or Server with GUI. Then, the Security Policy spoke should show the removal notice as an error.

[ggbecker]

I managed to test the changes, they look good. But, there is an issue when you select CIS profile, for example, then it will say the installation cannot proceed because of the xorg-x11-server-common package and that's expected but when I switch to a different profile that doesn't include the rule that removes this package, the software selection still thinks that the xorg-x11-server-common package is still missing and it doesn't allow to proceed the installation.

I'm not sure if this problem was introduced by this PR of if it's there already. I'll investigate a bit more.

[matejak]

Good catch. When I check the code, it doesn't seem that it has a way how to "forget" an old profile when you select a new one. I look forward to your analysis, and I predict that the problem already was there, and that it can be fixed, maybe even in this PR.

[ggbecker]

As we predicted. The problem was already there. If I select a profile which tries to remove this package and then using Server with GUI for example, it blocks the installation, even if you select another profile that doesn't container the rule. The only solution is to restart the installation process.

Note: If you select first the Software Selection Server With GUI, then play around with profiles... it will allow the installation... but it might break in the middle. I guess the validation of packages is done when you enter/exit the respective spoke.

[matejak]

So by investigating further, there actually is some kind of "undo", but it may not be working properly. I have verified that this code is executed when one switches a profile: https://github.com/OpenSCAP/oscap-anaconda-addon/blob/rhel8-branch/org_fedora_oscap/rule_handling.py#L683
However, I was able to reproduce that the Software Selection spoke still thinks that the xorg is on the blacklist.

[ggbecker]

So by investigating further, there actually is some kind of "undo", but it may not be working properly. I have verified that this code is executed when one switches a profile: https://github.com/OpenSCAP/oscap-anaconda-addon/blob/rhel8-branch/org_fedora_oscap/rule_handling.py#L683
However, I was able to reproduce that the Software Selection spoke still thinks that the xorg is on the blacklist.

This may indicate that the problem is on Anaconda side then.

Additional info:
I was able to reproduce the issue on RHEL8.2 as well which contains older version of Anaconda. It required a little bit more of clicking around but the issue is definitely there.

[matejak]

So it's probably indeed an Anaconda issue. I did following steps:

1. Select the workstation software selection
2. Choose the CIS profile
3. Go back to the software selection - after the Done button is clicked, there will be errors reported because of xorg.
4. Change the profile to e.g. e8
   4.9 (optional) - if one revisits the software selection, there are still xorg issues reported.
5. Go to software sources, make a modification (e.g. add a slash to a URL). Notice that both spokes "reload" after that.
6. Revisit the software selection - enter that spoke and click Done - the problem is now gone.

[scrutinizer-notifier]

The inspection completed: 1 updated code elements

[ggbecker]

Since the issue with software dependency is on the Anaconda side, I approve this pull request.

[ggbecker]

@matejak Do you plan to make any other change to this PR?

[matejak]

No, you can go ahead and merge it.