On Fri, 2024-10-11 at 13:26 +0200, Michael Schwendt via packaging wrote: > 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 > > https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages with all respect , I think renaming or moving is almost the same thing i.e. for example if we have foo-devel-doc and want to move to foo-doc we may use renaming rules . In tesseract case, the problem is that is not moving all the sub- package , so may have different rules > 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. -- Sérgio M. B. -- _______________________________________________ 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
