On 11/05/2015 10:47 AM, Cole Robinson wrote: > On 11/05/2015 12:33 PM, Daniel P. Berrange wrote: >> The patches for introducing virtlogd will be significantly >> simplified if we don't need to worry about parsing stderr >> during startup. This is required prior to QEMU 0.11 so >> that we can get the dyanamically allocated /dev/pty/NNN >> paths. >> >> The QEMU 0.12.1 release was shipped in RHEL-6 vintage >> distros and is already quite old, so seems like a fair >> target version to aim for as the minimum required. >> > > Up next... drop support for building on RHEL-5 ? :) Would mean we could > simplify the RPM spec quite a bit Upstream qemu 2.4 has already effectively dropped support for RHEL 5, and the upcoming qemu 2.5 takes that even further by bumping minimum glib and python requirements so that it is no longer possible to develop qemu out of the box on RHEL 5. My argument is that libvirt should be buildable out of the box on any platform where its underlying hypervisor support is also buildable out of the box, as follows: There are two types of users that stick to older systems: 1. You are using an older system on purpose, for its stability, and you don't care about newer features. You are thus relying on your vendor to ship you stable qemu and libvirt, and won't be building out of the box. Upstream may not build on your system, but you don't care, because your vendor is backporting the relevant upstream patches to your older setup. 2. You are using an older system for its stability elsewhere, but you want to augment that system to also take advantage of newer upstream features faster than your vendor is doing in their pre-built versions. As long as the entire stack can be built out of the box on your system, then you do not need your vendor for your virt stack. But you are also admitting that you don't need your vendor. As soon as one part of the stack no longer builds out of the box, you probably aren't going to build any of the rest of the stack. But you've already proven you can build the versions you need, so you no longer need to track upstream. If upstream comes out with a feature you need, then it is time to consider upgrading, and putting the burden of stability back on your vendor, than to manage an ever-increasing set of things that no longer build by yourself. All other users are using newer systems. Here, whether relying on the vendor to backport stable patches, or building out of the box, it is not a problem because the package can still be built on that system's prerequisites. So I would be in favor of dropping RHEL 5 as an out-of-the-box build platform for upstream libvirt. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list