If you install E-2 the package P in version 1.0.2 is installed. This solves erratum E-1 with package P in version 1.0.1 automatically. The UI should make this visible and auto-select E-1 if you click on E-2.
A thought on how this proposal might work: if a newer errata’s package-list is a proper-superset of an older errata, then applying newer “implies” you have applied the older one as well.
Also one of the problems we had in @Bernhard_Suttner 's example, was that if you apply Errata E-2 with Package P-1.0.2, then Errata E-1 with Package P-1.0.1 will now never disappear from your list of applicable errata. You can apply it, but because there is nothing for it to do, this is a noop and the Errata does not get marked as applied.
What Grant said should already be the case in Katello:
In Katello, Errata applicability is completely based on the applicability of the packages within the erratum.
In @Bernhard_Suttner 's example, if you install E-2, E-1 should not longer be applicable because P-1.0.1 should not be applicable to the system. Its EVR (epoch-version-release), being 1.0.2 is now newer than 1.0.1.
Now, if E-1 has some other package that is applicable to the system, then E-1 will be applicable and you can apply it. Applying E-1 then should install this other hypothetical package and thus stop being applicable.
If you’re seeing E-1 continue to be applicable, that sounds like a bug with the underlying RPM package applicability. After the newer erratum is installed, the applicability for the host should get regenerated.
Assuming there’s a bug here, do you have any reproducer steps @quba42 that I could try? I’d also like to know what Katello version you’re on.
@iballou Thanks for this answer. It’s possible (I am not at all sure) the case I remember was with Debian/Ubuntu errata (which is not merged to upstream Katello). Having you confirm that this should work for RPM (and also your explanation of the applicability design) is a great help, so we know where to direct our attention.
In case I do encounter the situation I described within RPM world, I now know that to be a bug, and would open a ticket with the exact reproducer.