Obsoleted-by: would be useful in some cases

[brianjmurrell]

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?

[1] I don't need to be told that 8.3 is no longer supported, can have security risks, etc. I know that. That doesn't stop other people from still using it, perhaps while they wait for corporate IT departments to quality 8.4, etc.

[Conan-Kudo]

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.

[mikhailnov]

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

[brianjmurrell]

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.

[Conan-Kudo]

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. 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.

[ffesti]

Looks like the conclusion in 2021 was that Obsoleted-by: is not the solution. Closing.