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

[Pavel Hrdina]

On Fri, Jun 24, 2016 at 04:11:52PM +0100, Daniel P. Berrange wrote:
> On Fri, Jun 24, 2016 at 05:04:30PM +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).
> 
> Actually I did want to have a libvirt-libs RPM way back when we first
> added libvirt-client, but was out-voted. I'd be fine with seeing us
> introduce a libvirt-libs minimal package.

I'm for introducing libvirt-libs too.  I'm surprised that you've been out-voted
since it's a good practice to place shared libraries or other files into
separate package.

Pavel