On Wed, Jun 27, 2012 at 12:32:32AM -0700, Josh Triplett wrote: [..snip..] > That seems potentially reasonable. I don't think you necessarily need > to bother splitting libvirt-daemon (/usr/sbin/libvirtd) from > libvirt-client (virsh and similar), though; a few tiny binaries won't > make a difference, as long as they don't run by default. Likewise for > the documentation unless it takes up a lot of space. But other than > that, those splits make sense.
doc is already split out and there's a wishlist bug to split out virsh since ages so we can handle that as well. > > This would allow boxes to depend on libvirt-daemon-qemu only pulling in > > the one hypervisor. > > If a package wants to use libvirt for a specific hypervisor, couldn't > they just depend on libvirtd and that hypervisor? Why do you need > separate libvirt packages for each hypervisor? > > (Yes, I realize that Fedora did it that way. :) ) Because that't the only way to say: I want libvirt managed qemu or libvirt managed xen. We're currently handling this via recommends which doesn't work too great. "apt-get install libvirt-qemu" would do the trick then. > > I'm not sure we'll get this in place for wheezy though. > > I don't know if the GNOME team plans to ship 3.4 in wheezy. If they do, > which seems likely to me given their upload to unstable rather than > experimental, then at least the split of the init scripts needs to > happen before wheezy. > > Would you consider making an upload in the near future that just splits > off the configuration files (and /lib/systemd/system if you ship a > service file) into a separate package? The larger reorganization could > then wait until post-wheezy. > > (Suggestion: leave libvirt-bin as the package with the binaries, and > call the new package libvirt-daemon-config .) The config split is the harder part (moving around config files, renaming them, etc). Splitting out the hypervisor modules is the easy. It's more a matter of time on my side at the moment. But I'll try to start work on this for 0.9.13-rc2. Cheers, -- Guido -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
