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.
