https://bugzilla.redhat.com/show_bug.cgi?id=2260793
--- Comment #34 from Stephen Gallagher sgallagh@redhat.com --- (In reply to Kevin Kofler from comment #33)
As for the Provides: deprecated(), why would it not be up to me as the maintainer to decide whether my package should be deprecated or not? I actively maintain this and see no reason for it to be marked as deprecated. (That said, since this is not going to impact end users, this is at least negotiable. The Epoch is not.)
The purpose of the `deprecated()` virtual Provides: is to indicate to other packagers that new packages depending on this package are not allowed to enter the distribution (without a dispensation). For example, we don't allow new packages with a dependency on OpenSSL 1.1 and indicate this with the `deprecated()` Provides. It wasn't explicitly discussed in the meeting (and could be raised for official clarification if you desire), but my general feeling was that we were deciding to allow X11 support as roughly equivalent to a compatibility package. So I think the `deprecated()` indicator is sensible here, because we don't necessarily want an entire ecosystem growing out of these two packages.