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