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: > > On Mon, Apr 02, 2012 at 08:57:11PM +0100, Daniel P. Berrange wrote: > > > For a long timer we've had the ability to build each libvirt > > > driver as a loadable module. We have never used this by default > > > and as a result it constantly bit-rots. > > > > > > This series fixes various bugs, and then enables it by default > > > in configure. It also makes the PRMs use the loadable modules, > > > adding new new sub-RPMs for each module. We can now finally > > > install minimal libvirt binaries for each hypervisor. > > > > > > ie yum install libvirt-kvm > > > > > > will not pull in Xen libraries! > > > > Okay, I understand the principle, and this sounds good. I'm sorry > > for not having caught up the RPM server refactoring patch earlier, I > > would have discussed that scenario, and would have avoided me reverting > > your patch (I really dislike doing this, I guess that was the first > > time I ever did this) but this was IMHO too much change and too early. > > > > I completely agree with the scenario of being able to do > > > > yum install libvirt-kvm > > > > and have libvirt daemon, the bits for the daemon qemu/kvm support, > > and related configuration files being pulled in, as well as hooking > > up the hypervisor dependency. But to me that means one specific > > libvirt-kvm package (tied to the daemon anyway the client should > > be agnostic about it), not two ! > > > > We should aim at minimizing the number of actual packages while > > still providing the needed modularization. So I would expect: > > - libvirt (the server and its basic config file) > > We can't do that, because changing the base 'libvirt' RPM in this > way will break the upgrade path - we need semantics of doing > 'yum install libvirt' to remain unchanged from before. okay, libvirt is the server package, that is full blown version... we can't change that, you're right ! > > - libvirt-client (as usual) > > - libvirt-devel (as usual) > > - libvirt-lock-sanlock (as usual) > > - libvirt-python (as usual) > > Indeed, there was/is no need to change the client side parts - only > the server side. > > > - libvirt-kvm (can we merge -kvm and -qemu ?) > > It is not desirable to merge them. In Fedora we don't want to force the > install of all the QEMU emulators - we only want to pull in the qemu-kvm > emulator most of the time. If apps depend on libvirt-kvm, they will get > only the KVM stack, while if they depend on libvirt-qemu they will get > the full QEMU stack. In RHEL of course there is no QEMU so that sub-RPM > disappears. okay, let's keep that split, that's 2 different audiences anyway, but I would expect then to share the same .so for the driver > > - libvirt-xen > > - libvirt-lxc > > - libvirt-uml > > - libvirt-network (our default network config) > > We need each dlopen'd .so file to be in a separate RPM. eg so that when > you install KVM, you don't pull in xen-libs. As well as the hypervisor > drivers though, you have the other pieces like the network/storage/nodedev > drivers. As well as the need to split the virbr0 / nwfilter config files > out, we get a minimum RPM set with actual %file payloads: > > - 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 ! > - libvirt-daemon-config-nwfilter - Just the firewall configs and libvirt-daemon-nwfilter the fact that the rpm contains config files, or .so, or binaries the user should care only of what functionality is provided. 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 !) > - 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. > For the sake of backwards compatibility / upgrade path we need: > > - libvirt - Virtual RPM, which Requires all of the above RPMs, to > ensure that it pulls in everything that the old libvirt > RPM always had. I really dislike "virtual rpms" . When we splitted -client and the server part we reassigned the server part to the old package, and that worked well since we still had the full dependency chain. Maybe we can't avoid that now, but I would hope that is the only virtual one ! > Sice it would be really tedious for apps to have to list Requires: on > each libvirt-daemon-driver-XXX module they care about we introduced > (and that would be upgrade-safe if we introduce more sub-drivers), > we need virtual packages: > > - libvirt-daemon-YYY - Virtual RPM pulls in the set of drivers > required for a specific hypervisor. One > for each YYY in (uml, qemu, kvm, xen, lxc). > Also depends on the appropriate hypervisr > RPM (eg 'qemu', 'qemu-kvm', 'xen') > > - libvirt-YYY - Virtual RPMs to pull in the set of drivers > required for a specific hypervisor, plus > the default config files. One for each > YYY in (uml, qemu, kvm, xen, lxc). > > I can see an argument that having 2 sets of virtual packages here is a > little bit overkill. definitely from my own POV, > Apps could just have added > > Requires: libvirt-daemon-kvm, libvirt-ademon-config-network make that libvirt-kvm, libvirt-daemon-bridge and that will sound sane to me. > if they really want KVM and the default configs. So we could get rid > of one of these virtual package sets without any real loss of flexibility. > > I don't see how we can practically eliminate any other sub-RPMS besides > these two, while retained flexibility upon install > > > for a separate split of the documentation currently in the -devel package > > I'm not so sure it's worth changing but I don't have a strong opinion > > Hmm, I didn't notice we had more docs in -devel. I created the -docs RPM > for all the docs that were in the main libvirt RPM - ie the entire copy > of the website. I should also have put all the API docs in there too I > reckon. yeah there is still the gtk-doc ones... 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