On Mon, Dec 16, 2024 at 12:13:26PM +0100, Xavier Bachelot wrote: > Le 2024-12-16 11:43, Daniel P. Berrangé a écrit : > > On Sat, Dec 14, 2024 at 01:40:45PM +0100, Paolo Bonzini wrote: > > > Il ven 13 dic 2024, 20:19 Richard W.M. Jones <rjo...@redhat.com> ha > > > scritto: > > > > > > > On Fri, Dec 13, 2024 at 07:37:10PM +0100, Paolo Bonzini wrote: > > > > > Yeah, and I don't think it should be merged, unless libnfs support is > > > > dropped > > > > > from the QEMU build in rawhide. > > > > > > > > Sure if there's no easy fix on the horizon, we can remove libnfs > > > > support temporarily. > > > > > > > > > > Can we just keep the old libnfs indefinitely? Are there any killer > > > features > > > for dependencies other than QEMU? > > > > QEMU needs fixing to work with both old and new libnfs. Even if > > Fedora pinned to old libnfs, we can be sure that sooner or later > > the new libnfs will appear in other distros and thus will inevitably > > need to deal with this incompatibility. > > > > To answer a previous question, there's no hurry in switching to the new > libnfs 6, especially as all affected code will need to be patched to > acknowledge for the new API. However, it will indeed need to be fixed sooner > or later, I don't think upstream will maintain the old libnfs 5 branch.
As predicted this has already hit us on non-Fedora distros now. macOS builds are now broken becase they updated to libnfs6. Thomas has proposed disabling support for libnfs6 https://lists.nongnu.org/archive/html/qemu-devel/2024-12/msg04257.html which means libnfs will increasingly get dropped as a QEMU feature in distros until there's a fix on the QEMU side. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
