On Fri, 2016-06-24 at 17:04 +0200, Michal Privoznik wrote: > On 24.06.2016 16:06, Daniel P. Berrange wrote: > > On Fri, Jun 24, 2016 at 03:59:38PM +0200, Michal Privoznik wrote: > > > On 24.06.2016 15:33, Daniel P. Berrange wrote: > > > > On Fri, Jun 24, 2016 at 03:12:23PM +0200, Michal Privoznik wrote: > > > > > Currently, the daemon requires libvirt-admin.so because the > > > > > functions encoding/decoding RPC messages for admin APIs live > > > > > there. But this makes it very hard to split admin API into its > > > > > own separate package: if libvirt-admin.so is going to live in a > > > > > separate package than the daemon, either both packages must be > > > > > installed or none. > > > > > Solve this by statically linking the RPC message handling > > > > > functions with the daemon. > > > > > > > > I'm not sure I see any need for a separate package for libvirt-admin.so > > > > For libvirt-qemu.so and libvirt-lxc.so we keep them in libvirt-client > > > > RPM, and I'd expect libvirt-admin.so to be there too really. > > > > > > So libvirt-client would contain not only virsh (and other .so files) but > > > virt-admin binary too? Okay, if that's what we want my patch is useless. > > > If we, however, want a separate package for libvirt-admin (which is kind > > > of special compared to libvirt-qemu.so and libvirt-lxc.so), then I guess > > > we need this patch. > > > > Hmm, i guess libvirt-admin is only needed if libvirtd is actually > > present on the host. So I guess we could argue that virt-admin > > and libvirt-admin.so should just be a part of libvirt-daemon RPM. > > The more I think about it the more I think that our current split into > RPM packages has some minor flaws. For instance, libvirt-daemon requires > libvirt-client; just because libvirt-client has some libraries that are > required by the daemon too. > > So what if we: > > a) introduce libvirt-libs.rpm where all the libraries would go) > b) have libvirt-daemon depend on -libs instead of -client, > c) have libvirt-client install just virsh. > > This way we can enable users who really want to have just the daemon > installed on their system (e.g. because there's one centralized mgmt > point having the client libs/binaries). > > Or am I just too spoilt by gentoo? :-) That's pretty much how it's handled in Debian as well: libvirt0 contains the shared libraries[1], libvirt-clients contains the clients[2], and libvirt-daemon contains the daemons[3]. Of course both libvirt-clients and libvirt-daemon depend on libvirt0. I'd say go for it! [1] https://packages.debian.org/sid/amd64/libvirt0/filelist [2] https://packages.debian.org/sid/amd64/libvirt-clients/filelist [3] https://packages.debian.org/sid/amd64/libvirt-daemon/filelist -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list