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-de...@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-de...@centos.org
https://lists.centos.org/mailman/listinfo/centos-devel
_______________________________________________
packaging mailing list
packaging@gluster.org
https://lists.gluster.org/mailman/listinfo/packaging
