[PATCH] build: Require glib >= 2.56

Daniel P. Berrangé berrange at redhat.com
Tue Mar 2 10:16:43 UTC 2021


On Tue, Mar 02, 2021 at 09:05:11AM +0100, Pavel Hrdina wrote:
> On Tue, Mar 02, 2021 at 08:51:29AM +0100, Peter Krempa wrote:
> > On Mon, Mar 01, 2021 at 16:00:47 -0700, Jim Fehlig wrote:
> > > There are a few uses of g_autoslist in the qemu driver and likely
> > > more will come throughout the codebase in the future. g_autoslist
> > > first appeared in glib 2.56, so bump the minimum version.
> > > 
> > > https://developer.gnome.org/glib/stable/glib-Miscellaneous-Macros.html#g-autoslist
> > 
> > Hmm, oops g_autoslist was my doing, unfortunately I thought we had
> > guards in place to prevent using stuff from newer glib.
> > 
> > Now when glib was introduced Daniel provided the following analysis of
> > glib versions:
> > 
> >       RHEL-8: 2.56.1
> >       RHEL-7: 2.50.3
> >       Debian (Buster): 2.58.3
> >       Debian (Stretch): 2.50.3
> >       OpenBSD (Ports): 2.58.3
> >       FreeBSD (Ports): 2.56.3
> >       OpenSUSE Leap 15: 2.54.3
> >       SLE12-SP2: 2.48.2
> >       Ubuntu (Xenial): 2.48.0
> >       macOS (Homebrew): 2.56.0
> > 
> > 
> > (commit 58e7c9bc05106c2fb76f9a72497bfc1b28988d71 )
> > 
> > 
> > Out of the above, this would exclude RHEL-7, Debian (Stretch), OpenSUSE
> > Leap 15, SLE 12 and Ubuntu Xenial.
> > 
> > At this point some of the distros went out of the support window:
> > 
> > OpenSUSE LEAP 15 -> currently supported is LEAP 15.2, which has 2.62
> > SLE12 -> SLE15 is now more than 2 years out
> > Ubuntu (Xenial) -> Ubuntu (Bionic) is more than 2 years out (2.56)
> > Debian (Stretch) -> Debian (Buster) was released in July of 2019, but
> >                     stretch is EOL (even our CI dropped it [1]
> > 
> > Now the problem is with:
> > 
> > RHEL-7 - > RHEL-8 was released in May of 2019
> > 
> > Thus we are 2 months out of dropping support for RHEL-7. On the other
> > hand starting from RHEL-7.6/CentOS7.6 glib was updated to 2.56, so on a
> > updated rhel-7/centos-7 the package will work. I'm not sure though how
> > we approach the update of package during the lifetime of the distro as
> > our platform support policy isn't clear on that [2].
> > 
> > My vote definitely goes for bumping the version.
> > 
> > [1] https://gitlab.com/libvirt/libvirt-ci/-/commit/5abf5e7e23263f839f4ff795883d1c67295a1e21
> > [2] https://libvirt.org/platforms.html
> 
> I would say that we can assume that we support only the latest minor
> version even though our support policy doesn't state that explicitly.
> 
> Looking at this page [1] it seems that RHEL-7 by default supports only
> the latest minor version unless you are paying customer and opt for EUS.
> I don't thing we need to cover this specific use-case.

The original 2.48 version was already from a 7.x minor release rebase
at that original point in time.

> 
> So I vote for bumping the version as well.
> 
> Reviewed-by: Pavel Hrdina <phrdina at redhat.com>
> 
> [1] <https://access.redhat.com/support/policy/updates/errata/>



Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list