Hi!
I'd like some feedback on the following scenario that had caused an implicit conflict because of moving shared libs from the main package to a subpackage:
| transaction failed: Rpm transaction failed. | - file /usr/lib64/libtesseract.so.5.4.1 from install of | tesseract-libs-5.4.1-4.fc41.x86_64 conflicts with file from package | tesseract-5.4.1-2.fc41.x86_64
The package maintainer's choice of a fix was to add
Conflicts: tesseract < 5.4.1-4
to "tesseract-libs" whereas common packaging practice has been to prefer a strict dependency instead, with
Requires: tesseract-libs%{?_isa} = %{version}-%{release}
in package "tesseract".
In Fedora packaging we've tried to avoid explicit conflicts for many years. Searching the guidelines, I only find this entry from 2013, which is about "acceptable use" but not a strict MUST:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_splitt...
Could this be revisited and refined as to be clear about the scenario of a package split? Specifically, _any_ file moved between [sub]packages could cause an implicit conflict during system updates. As such, explicit "Requires" have been the primary choice to add a strict dependency. If an explicit "Conflicts" tag is needed, the guidelines ought to make that clear.
On Thu, 2024-10-10 at 14:01 +0200, Michael Schwendt via packaging wrote:
Hi!
I'd like some feedback on the following scenario that had caused an implicit conflict because of moving shared libs from the main package to a subpackage:
transaction failed: Rpm transaction failed. - file /usr/lib64/libtesseract.so.5.4.1 from install of tesseract-libs-5.4.1-4.fc41.x86_64 conflicts with file from package tesseract-5.4.1-2.fc41.x86_64
The package maintainer's choice of a fix was to add
Conflicts: tesseract < 5.4.1-4
IMO , this is wrong should be:
Obsoletes: tesseract < 5.4.1-4
and maybe also :
Provides: tesseract = 5.4.1-4
to "tesseract-libs" whereas common packaging practice has been to prefer a strict dependency instead, with
Requires: tesseract-libs%{?_isa} = %{version}-%{release}
in package "tesseract".
In Fedora packaging we've tried to avoid explicit conflicts for many years. Searching the guidelines, I only find this entry from 2013, which is about "acceptable use" but not a strict MUST:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_splitt...
Could this be revisited and refined as to be clear about the scenario of a package split? Specifically, _any_ file moved between [sub]packages could cause an implicit conflict during system updates. As such, explicit "Requires" have been the primary choice to add a strict dependency. If an explicit "Conflicts" tag is needed, the guidelines ought to make that clear.
On Thu, 10 Oct 2024 13:06:55 +0100, Sérgio Basto wrote:
IMO , this is wrong should be:
Obsoletes: tesseract < 5.4.1-4
and maybe also :
Provides: tesseract = 5.4.1-4
No, the main package isn't obsolete, but continues to exist while the shared libs are moved to a new -libs subpackage.
On Thu, 2024-10-10 at 14:10 +0200, Michael Schwendt via packaging wrote:
On Thu, 10 Oct 2024 13:06:55 +0100, Sérgio Basto wrote:
IMO , this is wrong should be:
Obsoletes: tesseract < 5.4.1-4
and maybe also :
Provides: tesseract = 5.4.1-4
No, the main package isn't obsolete,
only < 5.4.1-4
but continues to exist while the shared libs are moved to a new -libs subpackage.
On Thu, 10 Oct 2024 17:30:05 +0100, Sérgio Basto wrote:
IMO , this is wrong should be:
Obsoletes: tesseract < 5.4.1-4
and maybe also :
Provides: tesseract = 5.4.1-4
No, the main package isn't obsolete,
only < 5.4.1-4
Then same comment as before: if that is how a package split ought to be handled in order to avoid an implicit conflict causing an update transaction check to fail, the packaging guidelines are in need of an update.
RPM itself can handle the package split without problems if there's no Conflicts tag set:
# rpm -Uvh tesseract-5.4.1-6.fc41.x86_64.rpm tesseract-libs-5.4.1-6.fc41.x86_64.rpm Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:tesseract-libs-5.4.1-6.fc41 ################################# [ 33%] 2:tesseract-5.4.1-6.fc41 ################################# [ 67%] Cleaning up / removing... 3:tesseract-5.4.1-2.fc41 ################################# [100%]
# rpm -q --conflicts tesseract-libs # rpm -qR tesseract|grep ^tess tesseract-langpack-eng tesseract-libs(x86-64) = 5.4.1-6.fc41
Perhaps that's insufficient as a test, but RPM doesn't detect a conflict.
On Thu, Oct 10, 2024 at 8:02 AM Michael Schwendt via packaging packaging@lists.fedoraproject.org wrote:
Hi!
I'd like some feedback on the following scenario that had caused an implicit conflict because of moving shared libs from the main package to a subpackage:
| transaction failed: Rpm transaction failed. | - file /usr/lib64/libtesseract.so.5.4.1 from install of | tesseract-libs-5.4.1-4.fc41.x86_64 conflicts with file from package | tesseract-5.4.1-2.fc41.x86_64
The package maintainer's choice of a fix was to add
Conflicts: tesseract < 5.4.1-4
to "tesseract-libs" whereas common packaging practice has been to prefer a strict dependency instead, with
Requires: tesseract-libs%{?_isa} = %{version}-%{release}
in package "tesseract".
In Fedora packaging we've tried to avoid explicit conflicts for many years. Searching the guidelines, I only find this entry from 2013, which is about "acceptable use" but not a strict MUST:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_splitt...
Could this be revisited and refined as to be clear about the scenario of a package split? Specifically, _any_ file moved between [sub]packages could cause an implicit conflict during system updates. As such, explicit "Requires" have been the primary choice to add a strict dependency. If an explicit "Conflicts" tag is needed, the guidelines ought to make that clear.
The Requires was already there, it just wasn't enough.
https://src.fedoraproject.org/rpms/tesseract/blob/rawhide/f/tesseract.spec#_...
On Thu, 10 Oct 2024 08:33:07 -0400, Neal Gompa wrote:
The Requires was already there, it just wasn't enough.
https://src.fedoraproject.org/rpms/tesseract/blob/rawhide/f/tesseract.spec#_...
The then packaging guidelines ought to get an update that makes it a MUST. Hundreds of package splits have been done without adding explicit Conflicts tags.
On Thu, 2024-10-10 at 14:01 +0200, Michael Schwendt via packaging wrote:
Hi!
I'd like some feedback on the following scenario that had caused an implicit conflict because of moving shared libs from the main package to a subpackage:
transaction failed: Rpm transaction failed. - file /usr/lib64/libtesseract.so.5.4.1 from install of tesseract-libs-5.4.1-4.fc41.x86_64 conflicts with file from package tesseract-5.4.1-2.fc41.x86_64
The package maintainer's choice of a fix was to add
Conflicts: tesseract < 5.4.1-4
to "tesseract-libs" whereas common packaging practice has been to prefer a strict dependency instead, with
Requires: tesseract-libs%{?_isa} = %{version}-%{release}
in package "tesseract".
In Fedora packaging we've tried to avoid explicit conflicts for many years. Searching the guidelines, I only find this entry from 2013, which is about "acceptable use" but not a strict MUST:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_splitt...
we have this guideline https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-repla...
Could this be revisited and refined as to be clear about the scenario of a package split? Specifically, _any_ file moved between [sub]packages could cause an implicit conflict during system updates. As such, explicit "Requires" have been the primary choice to add a strict dependency. If an explicit "Conflicts" tag is needed, the guidelines ought to make that clear.
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-repla...
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.
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-repla...
https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting...
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.
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...
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@lists.fedoraproject.org
-
Michael Schwendt -
Neal Gompa -
Sérgio Basto