On Tue, Apr 03, 2012 at 02:08:11PM +0100, Daniel P. Berrange wrote: > On Tue, Apr 03, 2012 at 05:41:57PM +0800, Daniel Veillard wrote: > > On Tue, Apr 03, 2012 at 10:06:02AM +0100, Daniel P. Berrange wrote: > > > On Tue, Apr 03, 2012 at 04:22:59PM +0800, Daniel Veillard wrote: > > > > - libvirt-daemon - Just the libvirtd daemon, no drivers, no configs > > > - libvirt-daemon-config-network - Just the virbr0 configs > > > > let's rename to libvirt-daemon-bridge then ! > > No, I explicitly chose to have -config' in the name, because this > really is just the config files, and we might want to use the > name 'libvirt-daemon-bridge' at some point in the future. > > > > - libvirt-daemon-config-nwfilter - Just the firewall configs > > > > and libvirt-daemon-nwfilter > > Again, I want config there to ensure that the libvirt-ademon-nwfilter > RPM name is availble for future use. > > > the fact that the rpm contains config files, or .so, or binaries the > > user should care only of what functionality is provided. > > The actual nwfilter functionality is provided in the libvirt-daemon > RPM, so to suggest they need to use libvirt-daemon-nwfilter is > misleading - this is only some default config files which apps > do not need to use if they don't want them - oVirt uses its own > configs for example. okay ... > > If we split it that much then we must make sure that > > rpm -i libvirt-daemon-nwfilter > > will actually restart the server in the %post (and true for most of the > > others package, may turn into a challenge when installing 4 extension > > package and we want to avoid restarting the server 4 times !) > > In the re-post I did, I use %posttrans script to ensure it is restarted > once, at the end of the transaction. good ! > > > - libvirt-daemon-driver-XXX - Contains the dlopen'd modules per driver > > > or sub-driver. One for each XXX in: (uml, > > > qemu, xen, lxc, storage, network, nwfilter, > > > interface, nodedev, secrets) > > > > this is what I dislike, I would prefer to see > > libvirt-kvm and libvirt-daemon-driver-kvm to be merged (and hence > > my question about qemu and kvm because the .so would be shared I assume) > > unless there is a good story for having only the .so in the rpm > > that's the part I really reacted to when I made my tentative build for > > the release and that looks way to intricate to my taste. > > It is not possible to merge these to. For backwards compatibility, > we need 'libvirt' to depend on 'libvirt-daemon-driver-qemu'. We > do *not*, however, want 'libvirt' to pull in 'qemu' itself. > > It becomes clear when you consider what the entry points for > application dependancies are: > > /---> libvirt --------+---------> libvirt-daemon > | | ^ > | | | > | \---------> libvirt-daemon-driver-qemu > | | | > +---> libvirt-daemon-qemu ------------+--|------> qemu > | | > +---> libvirt-daemon-kvm ----------------+------> qemu-kvm > | > App Choice > > So 'yum install libvirt', does *not* pull in 'qemu', 'qemu-kvm' or 'xen' > > > If we merged the packages as you describe, we'd end up with > > > /---> libvirt --------+---------> libvirt-daemon > | | ^ > | \-------------\ | > | | | | > | | V | > |----------------------------|--> libvirt-daemon-driver-qemu ---> qemu > | | > | \------\ > | | > | V > |-------------------------------> libvirt-daemon-driver-qemu ---> qemu-kvm > | > App Choice > > > So, 'yum install libvirt' would end up pulling in every single hypervisor > we support (qemu, qemu-kvm, xen), which is not at all what we want. > > Separating the libvirt-daemon-XXX packages from the libvirt-daemon-driver-XXX > packages is key to achieving the goal of minimising install footprint, while > maintaining backwards compatibility with existing RPM deps. I still wonder if it is worth it then. Adding an extra empty rpm just for the sake or avoiding a explicit hypervisor dependency at the application level. The whole scheme adds N + 1 empty rpms just for avoiding that dep that the application need to explicitely state right now anyway. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list