On 09/06/2023 18:01, Peter Georg wrote: > > > 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. > remove 'liburing' from glusterfs release repos ? it'll make general updates cleaner after liburing downgrade. Not that I've collected some metrics but both qemu's & glusterfs run together fine and updated so, many! thanks. L.