[EPEL-devel] Re: Proposal: gate all stable release updates on rmdepcheck

On Tue, 2026-07-07 at 11:11 +0100, Richard W.M. Jones wrote:
> The trouble with this is that another packager might be unresponsive
> or be unable to fix or simple refuses to fix their package
> (eg. because of your SONAME update) and now you can't release that to
> anyone in a stable branch.  Even if your package is more core than the
> other person's blocking package.

Well, I see a few issues with that.

One, by policy, soname updates are rarely meant to happen on stable
releases at all. See the policy text I cited: "ABI changes in general
are very strongly discouraged, they force larger update sets on users
and they make life difficult for third-party packagers."

Two, if you *are* for some reason absolutely forced to make an ABI
change in a stable release, I think you absolutely should be on the
hook for making sure all dependencies are fixed. Even if one of their
packagers is non-responsive, you can send a pull request and ask a
proven packager to merge it after a sufficient period of inactivity. I
don't think it's practical at present to expect this for Branched or
Rawhide, which is why I'm not proposing it for those branches, but I
think it is reasonable in the *exceptional* and *unusual* case of ABI
changes in stable releases.

Three, if for some reason it is absolutely necessary to *both* change
an ABI *and* break some dependents of it in a stable release, I think
it is not particularly onerous to require you to file a waiver. The
filing of the waiver effectively acts as a record of the fact that you
were aware of your update breaking dependent packages and that you are
willing to defend this as being in some way correct or necessary.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @[email protected]
https://www.happyassassin.net



-- 
_______________________________________________
epel-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new