Re: [PATCH] daemon: Drop dependency on libvirt-admin.so

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]