From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJHK6-0007pY-LI for qemu-devel@nongnu.org; Thu, 05 Feb 2015 02:58:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJHK1-0003NZ-Ki for qemu-devel@nongnu.org; Thu, 05 Feb 2015 02:58:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJHK1-0003NG-Dc for qemu-devel@nongnu.org; Thu, 05 Feb 2015 02:57:57 -0500 From: Markus Armbruster References: <20150204113229.GN3032@redhat.com> <54D213E0.8090408@redhat.com> <20150204130041.GQ3032@redhat.com> <87egq5kcqh.fsf@blackfin.pond.sub.org> <87mw4thc0v.fsf@blackfin.pond.sub.org> Date: Thu, 05 Feb 2015 08:57:51 +0100 In-Reply-To: (Peter Maydell's message of "Wed, 4 Feb 2015 20:41:54 +0000") Message-ID: <87bnl8dc3k.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paolo Bonzini , QEMU Developers Peter Maydell writes: > On 4 February 2015 at 16:33, Markus Armbruster wrote: >> Peter Maydell writes: >>> On 4 February 2015 at 13:49, Markus Armbruster 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. If you can compile upstream QEMU, compiling GLib shouldn't be an insurmountable obstacle. > 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. Fair enough. > 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? "Worthwhile" is in the eye of the beholder. Chaining ourselves to 7+ year-old libraries means we get to work around annoyances (quick grep: commit f8833a3 01a2050), we compromise on testing when the libraries are actually old[*] (commit 9d41401), and certain improvements won't get done because they're too much of a bother (commit 02c4f26). These are all paper cuts. Is suffering them worthwhile? [*] Rule of thumb: if you want to run an upstream version of X, run it under an OS the upstream developers actually use every day, or do your own testing.