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