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 :|