On Wed, 18 Apr 2018 13:55:45 +0100
Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Wed, Apr 18, 2018 at 02:45:38PM +0200, Cornelia Huck wrote:
> > On Wed, 18 Apr 2018 14:38:37 +0200
> > Olaf Hering <o...@aepfle.de> wrote:
> >
> > > Since usage of g_realloc_n was introduced, glib-2.22 can not be used
> > > anymore.
> > > Fixes commit 418026ca43 ("util: Introduce vfio helpers")
> > >
> > > Signed-off-by: Olaf Hering <o...@aepfle.de>
> > > ---
> > > configure | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/configure b/configure
> > > index 6e9b994f21..81760ef45a 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -3369,7 +3369,7 @@ fi
> > > if test "$mingw32" = yes; then
> > > glib_req_ver=2.30
> > > else
> > > - glib_req_ver=2.22
> > > + glib_req_ver=2.24
> > > fi
> > > glib_modules=gthread-2.0
> > > if test "$modules" = yes; then
> > >
> >
> > Are we ready to give up support for whatever distro is still on 2.22?
> > (If yes, can we bump to an even newer glib version?) Or should we
> > rather solve this by adding a g_realloc_n implementation for that case?
>
> Version 2.22 was released in Sep 2009, so coming up for 9 years old now.
>
> At some point we should to declare that platforms shipping >= NNN year
> old versions of software are not a desirable target for QEMU. What is
> our desired NNN value - 9 years feels awfully long to me.
The curse of the enterprise distro, I suppose... (And they might have
backported certain features without bumping the version number - I've
run into that problem in the past.)
>
> For libvirt we recently decided to become more aggressive[1] in culling old
> distros as supportable targets, declaring we'll only support non-EOL
> distros (for short life distros), or for long life distros (RHEL, LTS, etc)
> the most recent version, and the recent minus-1 for 2 years overlap.
That does not seem unreasonable. What about things like the MacOS stuff
(like fink vs. homebrew, as Peter mentioned?) Other platforms?
>
> Should we formalize similar guidelines for QEMU to give developers a
> guide for when it is reasonable to increase the min required version of
> any 3rd party library ? glib is a mandatory dep, but we've countless
> other optional libraries we might wish to increase min versions for too,
> and no guide on when it is reasonable todo so.
If we decide on anything, we should definitely put it in writing :)
We've had this discussion way too often in the past...
