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 -- _______________________________________________ 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
