https://bugzilla.suse.com/show_bug.cgi?id=1209105 https://bugzilla.suse.com/show_bug.cgi?id=1209105#c13 James Fehlig <jfehlig@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #13 from James Fehlig <jfehlig@suse.com> --- (In reply to Dominique Leuenberger from comment #11)

https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/ df1c91ac7c9071ff4c943c1a0d7719cf1f7082ce/lib/services/libvirtd.pm#L47

Thanks! That makes it easier to identify the problem: The kvm_tools pattern [1] requires libvirt-daemon-qemu, which no longer requires libvirt-daemon. I've decomposed the libvirt-daemon package, both upstream [2] and downstream [3], in hopes of eventually deleting the monolithic libvirtd and libvirt-daemon package. I'm not really sure the best way to handle this upgrade scenario. One thing that comes to mind is detecting enabled/running libvirtd in pre scriptlet, then enable/start the modular daemon in posttrans. But that could get messy. E.g. which modular daemon? virtqemud? virtxend? virtlxcd? Some combination of them? And the test would continue to fail anyhow since it checks for libvirtd after the upgrade. Is there an easier solution I'm not considering? A weaker or different dependency relationship? I _think_ we want to support the upgrade scenario, but definitely don't want libvirtd and libvirt-daemon on new TW installs. [1] https://build.opensuse.org/package/view_file/openSUSE:Factory/patterns-serve... (line 230) [2] https://listman.redhat.com/archives/libvir-list/2023-January/237059.html [3] https://build.opensuse.org/package/rdiff/Virtualization/libvirt?linkrev=base&rev=968 -- You are receiving this mail because: You are on the CC list for the bug.