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. > 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. > > - 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. Rgards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list