On Mon, Mar 01, 2021 at 05:37:14PM +0300, Michael Tokarev wrote: > So for now, if we drop this dependency of qemu-system-common on > qemu-system-foo, > this issue should go away.
The satisfiability issue would go away, but then libvirt would use the hosts' qemu-system-common, which cannot be run. So cross building would continue to fail. > Next, the question is why qemu-system-common is needed to BUILD libvirt. > This is because libvirt's build system finds the path of qemu-bridge-helper > (and uses default path which is not the one used on debian). Which immediately > leads to the next question: why libvirt uses qemu-bridge-helper in the first > place. I think this is the right question to ask. I didn't go as far in the submission and only asked for how it should express the dependency, but clearly this one comes next. > The thing is that on debian we still don't add set-uid bit to > qemu-bridge-helper, > so this place in libvirt will never actually work. libvirt can manage network > by its own, or, if run unprivileged (is it ever possible?), it will try to > use qemu-bridge-helper, and that will fail too by default (unless the user > explicitly enabled set-uid bit for qemu-bridge-helper. > > I looked at where qemu-bridge-helper is located on debian. It is > /usr/lib/qemu/, - > which is not commonly used path, the default is /usr/libexec/. Now there's 3rd > question: what if we'll try to move this executable to the place where it is > installed to by default? How we can change libvirt? Adding versioning breaks/ > requires seems to be the only way. > > I think we should move qemu-bridge-helper to the default place, maybe even now > before bullseye, and drop qemu-system-common from libvirt's build-depends. At > the same time drop the fake versioned deps of qemu-system-common. And decide > when/how we should use the bridge-helper in the first place. > > What do you think? This is lots of different but related pieces. I've not fully grasped the implications, but the line of reasoning makes sense to me. I do wonder though who "you" is here. I think it should mostly be the libvirt maintainers (added to Cc). Any solution that includes dropping the qemu-system-common build dependency from libvirt fully resolves this issue from my pov. Consequently, I propose: retitle -1 libvirt should stop build-dependening on qemu-system-common and stop using qemu-bridge-helper reassign -1 src:libvirt All the proposed qemu changes may make sense of their own, but are irrelevant to the satisfiability issue at hand if libvirt drops that build dependency. Helmut
