[gluster-packaging] [CentOS-devel] Qemu VS GlusterFS - liburing rpm conlisions

[lejeczek]

On 01/06/2023 14:46, Niels de Vos wrote:
> On Thu, 2023-06-01 at 09:51 +0200, lejeczek via CentOS-devel wrote:
>> On 31/05/2023 20:30, Troy Dawson wrote:
>>> Just to be clear, this is the glusterfs from the glusterfs
>>> SIG,
>>> not the gluster that comes standard with CentOS Stream 9.
>>>
>>>
>>> On Wed, May 31, 2023 at 12:30 AM lejeczek via CentOS-devel
>>> <centos-devel at centos.org>  wrote:
>>>
>>>      Hi guys.
>>>      Just to let you know that with GlusterFS & latest qemu
>>>      updates - on Centos 9 I'd image most will have these -
>>>      there are conflicts which brake update:
>>>
>>>      -> $ dnf update
>>>
>>>      Error:
>>>       Problem 1: package qemu-img-17:8.0.0-4.el9.x86_64
>>>      from appstream requires liburing.so.1()(64bit), but
>>>      none of the providers can be installed
>>>        - package qemu-img-17:8.0.0-4.el9.x86_64 from
>>>      appstream requires liburing.so.1(LIBURING_0.1)(64bit),
>>>      but none of the providers can be installed
>>>        - package qemu-img-17:8.0.0-4.el9.x86_64 from
>>>      appstream requires liburing.so.1(LIBURING_0.2)(64bit),
>>>      but none of the providers can be installed
>>>        - cannot install both liburing-0.7-7.el9.x86_64 from
>>>      appstream and liburing-2.0-1.el9s.x86_64 from @System
>>>        - cannot install the best update candidate for
>>>      package qemu-img-17:8.0.0-2.el9.x86_64
>>>        - cannot install the best update candidate for
>>>      package liburing-2.0-1.el9s.x86_64
>>>       Problem 2: package
>>>      glusterfs-server-11.0-1.el9s.x86_64 from @System
>>>      requires liburing.so.2()(64bit), but none of the
>>>      providers can be installed
>>>        - package glusterfs-server-11.0-1.el9s.x86_64 from
>>>      @System requires liburing.so.2(LIBURING_2.0)(64bit),
>>>      but none of the providers can be installed
>>>        - cannot install both liburing-0.7-7.el9.x86_64 from
>>>      appstream and liburing-2.0-1.el9s.x86_64 from @System
>>>        - cannot install both liburing-0.7-7.el9.x86_64 from
>>>      appstream and liburing-2.0-1.el9s.x86_64 from
>>>      centos-gluster11
>>>        - cannot install both liburing-0.7-7.el9.x86_64 from
>>>      appstream and liburing-2.0-1.el9s.x86_64 from
>>>      centos-gluster11-test
>>>        - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from
>>>      appstream requires liburing.so.1()(64bit), but none of
>>>      the providers can be installed
>>>        - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from
>>>      appstream requires liburing.so.1(LIBURING_0.1)(64bit),
>>>      but none of the providers can be installed
>>>        - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from
>>>      appstream requires liburing.so.1(LIBURING_0.2)(64bit),
>>>      but none of the providers can be installed
>>>        - cannot install the best update candidate for
>>>      package qemu-kvm-core-17:8.0.0-2.el9.x86_64
>>>        - cannot install the best update candidate for
>>>      package glusterfs-server-11.0-1.el9s.x86_64
>>>       Problem 3: problem with installed package
>>>      liburing-2.0-1.el9s.x86_64
>>>        - cannot install both liburing-0.7-7.el9.x86_64 from
>>>      appstream and liburing-2.0-1.el9s.x86_64 from @System
>>>        - cannot install both liburing-0.7-7.el9.x86_64 from
>>>      appstream and liburing-2.0-1.el9s.x86_64 from
>>>      centos-gluster11
>>>        - cannot install both liburing-0.7-7.el9.x86_64 from
>>>      appstream and liburing-2.0-1.el9s.x86_64 from
>>>      centos-gluster11-test
>>>        - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from
>>>      appstream requires liburing.so.1()(64bit), but none of
>>>      the providers can be installed
>>>        - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from
>>>      appstream requires liburing.so.1(LIBURING_0.1)(64bit),
>>>      but none of the providers can be installed
>>>        - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from
>>>      appstream requires liburing.so.1(LIBURING_0.2)(64bit),
>>>      but none of the providers can be installed
>>>        - problem with installed package
>>>      qemu-kvm-core-17:8.0.0-2.el9.x86_64
>>>        - package qemu-kvm-core-17:8.0.0-2.el9.x86_64 from
>>>      @System requires qemu-kvm-common = 17:8.0.0-2.el9, but
>>>      none of the providers can be installed
>>>        - package qemu-kvm-core-17:8.0.0-2.el9.x86_64 from
>>>      appstream requires qemu-kvm-common = 17:8.0.0-2.el9,
>>>      but none of the providers can be installed
>>>        - cannot install both
>>>      qemu-kvm-common-17:8.0.0-4.el9.x86_64 from appstream
>>>      and qemu-kvm-common-17:8.0.0-2.el9.x86_64 from @System
>>>        - cannot install both
>>>      qemu-kvm-common-17:8.0.0-4.el9.x86_64 from appstream
>>>      and qemu-kvm-common-17:8.0.0-2.el9.x86_64 from appstream
>>>        - cannot install the best update candidate for
>>>      package qemu-kvm-common-17:8.0.0-2.el9.x86_64
>>>      (try to add '--allowerasing' to command line to
>>>      replace conflicting packages or '--skip-broken' to
>>>      skip uninstallable packages or '--nobest' to use not
>>>      only best candidate packages)
>>>
>>>      many thanks, L.
>>>      _______________________________________________
>>>
>> Yes, from SIG.
>> centos-release-gluster11-1.0-1.el9s.noarch
> liburing.so.1(LIBURING_0.1)(64bit) - needed by qemu
> liburing.so.2(LIBURING_2.0)(64bit) - needed by glusterfs
>
> I guess liburing was not available in earlier versions, and was
> therefore added to the gluster repository. We'll have to remove the
> gluster version and rebuild the package against the liburing version
> that is now part of CentOS Stream 9.
>
> The gluster repository seems to have a newer liburing version, which
> makes it difficult to downgrade to the appstream version for users that
> have the glusterfs-server package installed. Users in this situation
> may need to add --allowerasing while updating to the a rebuild of the
> glusterfs package.
>
> Does anyone have an idea on how this can be handled best?
>
> Thanks,
> Niels
>
As a consumer purely, I'll suggest the obvious(?)
I would reckon that the first/easiest? would be, to check v1 
VS v2 compatibility - which probably is not there. (perhaps 
there is some "compat" layer) but worth trying.
But, If v2 was backwards-compatible then, rebuild (qemu/kvm 
first?) packages to allow for 'liburing' higher version(s) - 
that would be straightforward.
Eventually have glusterFS gang to consume what is in 
'base/app' (with natural & expected feedback)
many thanks, L.