On Thu, 10 Oct 2024 22:46:24 +0100, Sérgio Basto wrote: > we have this guideline > https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages > That is the well known guidelines about renaming/replacing packages, they don't cover the case of moving files to a new subpackage. The packaging scenario in this topic is that of shared libraries moving from main package to a new subpackage. That's not a package rename. That's not creating an obsolete package (to be removed) either. As a side-note, the purpose of the versioned Obsoletes tag in the case of replacing a package is only to uninstall that package while retaining the option to reintroduce it in the future with a higher EVR. No packager I'm aware of has ever followed the renaming/replacing guidelines when creating a new subpackage and moving files to it. As shown, RPM can handle the presented case of a "tesseract" package split just fine. Is it only that some other package resolver frontends fail during the transaction check depending on the order in which they examine the packages in the update set? Is that regression? Has it always been like that? I see packagers performing package splits without adding Conflicts tags, and if those updates work only out of coincidence and can fail in the same way depending on package set ordering, that's bad and ought to be covered by the packaging guidelines. -- _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/packaging@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue