On Thu, Nov 05, 2015 at 11:05:53AM -0700, Eric Blake wrote: > 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: As a second criteria I also tend to consider what phase of life the OS vendor considers the platform to be in. ie even if QEMU had gone further and dropped RHEL-6, I would still consider RHEL-6 a valid target because it is still very much in the production phase of its lifecycle. Only once a platform is locked down into critical bug fix only stage, it is valid to consider discontinuing it in libvirt too > So I would be in favor of dropping RHEL 5 as an out-of-the-box build > platform for upstream libvirt. Regards, 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