Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels

[Peter Maydell <peter.maydell@linaro.org>]

On 4 February 2015 at 16:33, Markus Armbruster <armbru@redhat.com> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>> On 4 February 2015 at 13:49, Markus Armbruster <armbru@redhat.com> wrote:
>>> Remind me: what GLib version are we targeting, and why?
>>
>> Our current minimum is 2.12 (or 2.20 in Windows specific code),
>> and the reason is RHEL5/Centos 5.
>
> Any idea when we can move on?
>
> Don't get me started on the wisdom of developing or deploying upstream
> QEMU on RHEL-*5*.

Not all of QEMU's use cases are KVM-using VM deployments, not all
compute cluster deployments are primarily directed to that, and
not all industries rev their supported OS platforms very fast.
For instance the EDA tools industry only added RHEL6 support
in 2012 for new design starts, and given the typical length of
a project it's not that implausible to still have RHEL5.

That said, we don't have to insist on supporting the most
ancient version of everything ever, and now might be a reasonable
time to move forward. I wouldn't want to move further forward
than RHEL6's version, though.

Moving beyond 2.22 would be awkward for me in that my OSX
box only has 2.22 because fink doesn't have anything newer.
I could probably deal with that somehow (switching to some
other package system, probably).

Debian stable is "2.33.12+really2.32.4-5" and oldstable
is "2.24.2-1" (and if my googling is right is an LTS release).

Ubuntu Lucid (LTS release) is 2.24; Precise (also LTS)
is 2.32.

Daniel says RHEL6 has 2.28.

That suggests to me that we could reasonably advance to
2.22 or 2.24 if it seemed beneficial, but not beyond that.
Is there anything particularly worthwhile that would get us?

-- PMM