Re: [Qemu-devel] [PATCH v1] configure: require glib-2.24

[Cornelia Huck]

On Wed, 18 Apr 2018 13:55:45 +0100
Daniel P. Berrangé <address@hidden> 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 <address@hidden> 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 <address@hidden>
> > > ---
> > >  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...