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

Peter Georg peter.georg at physik.uni-regensburg.de
Fri Jun 9 16:01:28 UTC 2023



On 09/06/2023 17.12, Niels de Vos wrote:
> On Fri, 2023-06-09 at 16:18 +0200, Peter Georg wrote:
>>
>>
>> On 09/06/2023 15.17, Niels de Vos wrote:
>>> On Fri, 2023-06-09 at 13:03 +0200, lejeczek via CentOS-devel wrote:
>>>>
>>>>
>>>> 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
>>>>>
>>>> Do you/devel guys (or anybody) have any fix ready to go into
>>>> the pipelines?
>>>> It'd good to know before I, rest of us, begin tinkering with
>>>> qemu & glusterfs.
>>>
>>> liburing-devel does not seem to be available in the buildroot that
>>> is
>>> configured for Gluster. Untagging the liburing-2 package causes
>>> builds
>>> to fail as it can not be installed.
>>
>> liburing-devel corresponding to the liburing version in appstream is
>> available in EPEL. However, EPEL is not enabled for
>> storage9s-gluster-11-el9s.
>>
> 
> Thanks for the info! If the EPEL version is compatible, it makes sense
> to get it added to the buildroot.
> 
>>> I am currently tending towards building glusterfs without liburing
>>> support. Maybe it makes sense to have the appstream(-devel?)
>>> repository
>>> included for the gluster buildroots, but I am not sure about that.
> 
> The above is what I'm making available in the ..-test repositories for
> CentOS Stream 11 & 10. Performance might be a little lower without
> liburing, but at least there are no conflicts when installing the
> packages next to QEMU. Test results are very welcome!
> 
>>> What do others think about this?
>>
>> Not directly related, but assuming you use liburing by utilizing EPEL
>> and at the same time also drop other dependencies from
>> storage9s-gluster-11-el9s which are satisfied by EPEL, the resulting
>> glusterfs rpms might actually end up being the very similar to what
>> we
>> currently provide for EL, i.e., in storage9-gluster-11-el9. The
>> glusterfs packages provided for EL do not suffers from these liburing
>> conflicts. Obviously these are build using RHEL build roots, but very
>> likely will work on Stream as well.
> 
> I like the idea, but it will still cause issues for users that are
> updating and have liburing-2.x installed. Maybe the package gets
> removed when glusterfs-server does not depend on liburing anymore? That
> would make a clean path for updating to a new version with liburing
> from EPEL at one point.

That's true. It does not help in that case. I do not think that DNF 
automatically removes installed dependencies on update if the new 
version does not require it anymore. So this would also not help to 
create a clean update path. I fear that users who have liburing-2.0 
installed on their system have to manually downgrade liburing once 
glusterfs-server does not depend on liburing anymore or before switching 
to a glusterfs-server build against liburing-0.7.
But I'm not a DNF expert, so I might be wrong.


> 
> Thanks,
> Niels
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel


More information about the packaging mailing list