On Fri, 11 Oct 2024 14:52:21 +0100, Sérgio Basto wrote: > 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 . Only and only if you want to get rid of foo-devel-doc. > In tesseract case, the problem is that is not moving all the sub- > package , so may have different rules Yep. 1) The "Provides" from those guidelines section would be wrong within the new (sub-)package as it does NOT replace the "old" package. 2) The "Obsoletes" tag from those guidelines section triggers uninstallation of the "old" base package. Which would also be wrong for the "RPM use case". Installing the new (sub-)package would attempt removal of the "old" base package, even if user wants to keep that one installed. Well, it may fail due to breaking dependencies (if any), but if there are no dependencies, it would be removed which would be unexpected. There's no hint that a new base package build is needed. 3) An explicit "Requires: %{name}%{_isa} = %{version}-%{release}" tag within the new (sub-)package would be wrong, too, since that new package does NOT need the base package. It's the opposite, the new base package strictly requires the new (sub-)package. On the contrary, a "Conflicts" tag at least gives the hint that a newer EVR of the "old" package is needed. A package repository based system update would pull in the newer build of the "old" package in any case, that's not the issue. Yet RPM handles the package split, if no "Obsoletes" or "Conflicts" tag exists in the new (sub-)package. Without accurate guidelines, packagers perform trial-and-error package splits. -- _______________________________________________ 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
