| What | Removed | Added |
|---|---|---|
| Status | NEW | CONFIRMED |
(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-server/patterns-server.spec?expand=1 (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