[Pkg-libvirt-maintainers] Bug#679074: Bug#679074: Please separate the init scripts for a system-wide libvirtd from the binaries usable for a per-user libvirtd

[Josh Triplett]

On Wed, Jun 27, 2012 at 08:07:15AM +0200, Guido Günther wrote:
> On Tue, Jun 26, 2012 at 10:01:08AM -0700, Josh Triplett wrote:
> > On Tue, Jun 26, 2012 at 06:08:06PM +0200, Guido Günther wrote:
> > > On Tue, Jun 26, 2012 at 01:05:36AM -0700, Josh Triplett wrote:
> > > > Package: libvirt-bin
> > > > Severity: normal
> > > > 
> > > > libvirt-bin currently includes both the libvirtd binary (and other
> > > > binaries) and the init scripts to start a system instance of libvirtd.
> > > > However, many applications using libvirt only need a per-user instance
> > > > of libvirtd, not a system instance.  For instance, gnome-boxes currently
> > > > depends on libvirt-bin to get libvirtd, but it doesn't need the system
> > > > instance.  According to gnome-boxes upstream, "you can connect to remote
> > > > instances, but the only thing that is sanely integrated in the UI is
> > > > creating local VMs in a per-user libvirtd".  (Anything else, including
> > > > the system instance, requires hand-entering a libvirt URI.)
> > > > 
> > > > So, please split the init scripts for a system-wide libvirtd instance
> > > > into a separate package from the binaries.
> > > 
> > > Does it really make sense to split out the init script? Wouldn't
> > > disabling the daemon also do the trick? 
> > 
> > The gnome metapackage now depends on gnome-boxes, and gnome-boxes
> > depends on libvirt-bin.  So, a default install of GNOME will end up with
> > a running system instance of libvirtd that nothing uses.  Users
> > shouldn't have to manually disable unused daemons that only get pulled
> > in by dependencies, especially as part of the default install of
> > something like GNOME.
> > 
> > This seems quite similar to the situation with Apache: gnome-user-share
> > depends on apache2.2-bin to get the binaries for the Apache web server,
> > which it can configure and run on a per-user basis to share files.  The
> > Apache packages ship the init scripts in a separate package, so that
> > installing gnome does not result in a running system-wide web server.
> 
> I see. I planed something for 0.9.13 like:
> 
> So something like:
> 
> libvirt-daemon
> libvirt-daemon-qemu
> libvirt-daemon-xen
> ...
> libvirt-client
> libvirt-doc
> 
> I'll add:
> 
> libvirt-daemon-config
> 
> containing the daemon config from /etc as well as the systemd startup
> scripts.

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.

> 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. :) )

> 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 .)

Thanks,
Josh Triplett