On Mon, Nov 24, 2025 at 11:19:11AM +0100, Peter Krempa wrote: > On Mon, Nov 24, 2025 at 10:00:34 +0000, Daniel P. Berrangé wrote: > > On Mon, Nov 24, 2025 at 09:44:11AM +0100, Peter Krempa via Devel wrote: > > > On Mon, Nov 24, 2025 at 09:32:52 +0100, Ján Tomko wrote: > > > > On a Monday in 2025, Peter Krempa via Devel wrote: > > > > > From: Peter Krempa <[email protected]> > > > > > > > > > > On Fedora 43 and newer the 'fuse-zfs' package was removed. Commit > > > > > bd30147e740 added an 'Obsoletes' directive so that the storage driver > > > > > core package will update properly but hardcoded the obsoleted version > > > > > as 11.4 (when the change was comitted) similarly to the old > > > > > sheepdog/rbd > > > > > packages. > > > > > > > > > > Unfortunately that doesn't work if the sub-package removal happened > > > > > based on an external dependancy, rather than complete removal of said > > > > > > > > *dependency > > > > > > > > > module in libvirt. If users have e.g. virt-preview repos enabled > > > > > they'll > > > > > get libvirt-11.9 currently installed, but the obsoleted version is > > > > > just > > > > > 11.4, thus upgrades to Fedora 43 with virt-preview are broken. > > > > > > > > > > > > > Isn't that the expected behavior? > > > > > > No. While it doesn't break for users not using virt-preview since > > > they're on 11.0.0-5.fc42 it is expected that updates from any version > > > actually work properly. > > > > IMHO if someone has virt-preview enabled and wants to upgrade to > > newer Fedora, they must first disable virt-preview and then do > > a "dnf distro-sync" to remove the virt-preview packages. > > We don't guarantee an upgrade path from virt-preview -> Fedora > > Technically I'm updating from virt-preview on 42 to virt-preview on 43. > > While I we likely don't claim any responsibility for any of the > virt-preview packages I don't see a logical reason why that shouldn't > work (and it does unless stuff like this happens). > > > > > > Fix this by obsoleting everything up to the current build. > > > > > > > > > > Fixes: bd30147e740d49fdb5844160e480ca34611f75e5 > > > > > Signed-off-by: Peter Krempa <[email protected]> > > > > > --- > > > > > libvirt.spec.in | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/libvirt.spec.in b/libvirt.spec.in > > > > > index 8314fbeb34..f1bfd5e652 100644 > > > > > --- a/libvirt.spec.in > > > > > +++ b/libvirt.spec.in > > > > > @@ -668,7 +668,7 @@ Obsoletes: libvirt-daemon-driver-storage-rbd < > > > > > 5.2.0 > > > > > %endif > > > > > Obsoletes: libvirt-daemon-driver-storage-sheepdog < 8.8.0 > > > > > %if !%{with_storage_zfs} > > > > > -Obsoletes: libvirt-daemon-driver-storage-zfs < 11.4.0 > > > > > +Obsoletes: libvirt-daemon-driver-storage-zfs <= %{version}-%{release} > > > > > %endif > > > > > > Looking at it now ... I wonder if this perhaps shouldn't be just '<' > > > given that it uses also %{release} > > > > Using "%{version}" in an Obsoletes is contrary to Fedora guidelines > > which want us to explicitly use the last version which had the feature > > available. > > Well that works well when the package itself removes the feature, but if > the package removal is caused by a dependancy it breaks if anyone build > something else than the official build. > > I guess the package guidelines will explicitly not support that, but > still it's terrible UX if someone uses anything else than an official > build. In addition the hardcoded version will also work for everyone who > used any other custom build package, just not the "later" ones. > > Finally the '11.4.0' doesn't even match what Fedora 42 ships, > (11.0.0-5.fc42) so I don't really understand why we can't use the latest > version macro in this case.
Actually now I've had coffee, I remember that we had a user complaining that we should not have added the Obsoletes at all in this case. While ZFS was removed from Fedora, it is still possible to get the ZFS tools and use them on Fedora with libvirt. We have precedent here with enabling cloud hypervisor and virtualbox both of which require 3rd party tools to be installed. Sheepdog was different because the sheepdog project is dead and the code was culled from libvirt/qemu entirely. IOW, we should just remove this "Obsoletes" line for ZFS, and re-enable the zfs sub-RPM. 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 :|
