Comment 10 for bug 1782031

I have been asked to give a second opinion regarding this SRU and I must say my feelings are a bit mixed.

On one side: I have to agree with Robie that this SRU might confuse existing users, those that would otherwise expect some checks coming back with "unknown" or "notchecked" to suddenly start failing. That might regress existing users in a sense, and that is bad.

On the other hand, both SCE and systemd probes/schema were not available nor supported for xenial before, right? Deliberately using functionality that's not supported and relying on it to return an ambiguous state at the end is not valid use IMO. I think it will be quite obvious for anyone using unsupported functionality and relying on it to stay as "unknown"/"notchecked" that eventually those might just start actually running. I think we should not really care about cases of such assumptions, since I somehow feel the developer was not doing the right thing anyway. We can't handle all use-cases. It's still a regression, yes, but a regression that most probably is caused by invalid use. Am I wrong?

Sure, this might be a problem for 'backport' cases, where there's the same check-set for different series, but since there was obviously a difference in functionality between one version an the other, the developer should have handled this better.

That being said, I do not have a strong opinion here. It's really hard to say what's the best way to go as I don't know how many users are there of openscap. I'm probably lacking that context to be able to give a solid answer. Regressing users is bad, but even normal, non-feature bugfixes can 'regress' people that are depending on the erroneous behavior.
I do remember one case handled by a more experienced SRU member that also involved slight regression of functionality for users that didn't use the package properly and the decision was to accept it. Not sure exactly if we have the same case here though. Somehow it does feel like it, but maybe I lack context here as well.