Peter Maydell <peter.mayd...@linaro.org> writes: > On 4 February 2015 at 16:33, Markus Armbruster <arm...@redhat.com> wrote: >> Peter Maydell <peter.mayd...@linaro.org> writes: >>> On 4 February 2015 at 13:49, Markus Armbruster <arm...@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.
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.
