> 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
