Re: [Rpm-maint] [rpm-software-management/rpm] Obsoleted-by: would be useful in some cases (#1768)
Closed #1768 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1768#event-10843533706 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Obsoleted-by: would be useful in some cases (#1768)
Looks like the conclusion in 2021 was that `Obsoleted-by:` is not the solution. Closing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1768#issuecomment-1790663062 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Obsoleted-by: would be useful in some cases (#1768)
> My being able to build hwloc2 with an Obsoleted-by: hwloc > 1 would achieve > this. No. It doesn't matter. Your package doesn't even depend on `hwloc1` but rather `libhwloc.so.5()(64bit)`. What you want is the development headers associated with that library to still be available. > And this is the problem. I am not the distro vendor. I am a third-party > software supplier. I cannot influence how the distro packages and can only > influence how I package but am missing the tools (Obsoleted-by: hwloc > 1) > needed to seemlessly integrate with the distro. I am also not going to get > the distro vendor to support that older release by supplying a backport for > it, so I have to do that myself. But I need to be able to do it in such a > manner that it integrates with the distro seemlessly. This is the wrong attitude to solve this problem. As an ISV myself, I have had decent engagements with Red Hat on matters like this in the past. If you don't talk to them about it, they'll never even know that it's a problem. > IMHO, RPM needs to not only support the distro vendor but needs to provide > the tools necessary for third-parties (i.e. non-distros) to integrate into > the distro. RPM upstream is distro-agnostic, we provide all the tools, it's up to the distro to offer them or use them. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1768#issuecomment-914385735___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Obsoleted-by: would be useful in some cases (#1768)
> I'm not sure what problem this solves. It sounds like the actual problem is > that you want `hwloc1` and `hwloc2` to be parallel installable on RHEL 8.3. No. That is not the problem. The problem is that in order to support both RHEL 8.4 and RHEL 8.3, while building on RHEL 8.4 (because one should not build one's software on unsupported older releases of the distro) I have to supply a backport of a newer version of a library for RHEL 8.3 installations due to that library breaking it's ABI on RHEL 8.4. But the package that that library backport is in needs to be cleanly replaced by the distro's package when that node is upgraded to RHEL 8.4. So to be clear, my package foo-1.0 requires hwloc-2.x on RHEL 8.4. But RHEL 8.3 doesn't supply hwloc-2.x but rather hwloc-1.x (notice the SO major version is not appended to the name like, say, SUSE does). So along with foo-1.0, I need to supply hwloc2-2.x that gets installed with my foo-1.0 when being installed on a RHEL 8.3 system. Since RHEL 8.4 supplies hwloc-2.x, only foo-1.0 gets installed on it. Now when a RHEL 8.3 system that my foo-1.0 and hwloc2-2.x is installed on is upgraded to RHEL 8.4, my supplied hwloc2 should be upgraded to the distro supplied hwloc-2.x. My being able to build hwloc2 with an _Obsoleted-by: hwloc > 1_ would achieve this. > This is pretty much a distro policy issue, and while RPM provides mechanisms > for solving this problem without needing `Obsoleted-by`, it's up to the > distro to use that. And this is the problem. I am not the distro vendor. I am a third-party software supplier. I cannot influence how the distro packages and can only influence how **I** package but am missing the tools (_Obsoleted-by: hwloc > 1_) needed to seemlessly integrate with the distro. I am also not going to get the distro vendor to support that older release by supplying a backport for it, so I have to do that myself. But I need to be able to do it in such a manner that it integrates with the distro seemlessly. IMHO, RPM needs to not only support the distro vendor but needs to provide the tools necessary for third-parties (i.e. non-distros) to integrate into the distro. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1768#issuecomment-914375153___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Obsoleted-by: would be useful in some cases (#1768)
> I'm not sure what problem this solves. It sounds like the actual problem is > that you want `hwloc1` and `hwloc2` to be parallel installable on RHEL 8.3. > This is pretty much a distro policy issue, and while RPM provides mechanisms > for solving this problem without needing `Obsoleted-by`, it's up to the > distro to use that. +1 Different sonames can be packaged in packages with different names -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1768#issuecomment-914229084___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Obsoleted-by: would be useful in some cases (#1768)
> An actual real world use case: > > * EL 8.3 has `hwloc-1.x` > * EL 8.4 has `hwloc-2.x` > > They are ABI incompatible. EL 8.4 also has `compat-hwloc1` which is ABI > compatible with `hwloc-1.x`, allowing software developed on EL 8.3 to work on > 8.4. > > But this also means that any software developer that needs to satisfy both EL > 8.3[1] and EL8.4 users needs to continue to build his software on EL 8.3 > until he no longer needs to satisfy EL 8.3 users. > > What would be more desirable would be to build one's software on the latest > release, 8.4 in this case and with it supply a compat-hwloc2 that has an > `Obsoleted-by: hwloc >= 2`. Users on 8.3 can install one's software along > with `compat-hwloc2` on their 8.3 systems and be able to use software that > was actually built with hwloc-2.x on an 8.4 system. > > What the `Obsoleted-by: hwloc >= 2` would be for is to have RPM remove > `compat-hwloc2` if/when the node is finally upgraded to 8.4 and `hwloc-2.x` > is installed. > > Thoughts? I'm not sure what problem this solves. It sounds like the actual problem is that you want `hwloc1` and `hwloc2` to be parallel installable on RHEL 8.3. This is pretty much a distro policy issue, and while RPM provides mechanisms for solving this problem without needing `Obsoleted-by`, it's up to the distro to use that. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1768#issuecomment-913911360___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
