Created attachment 116887 [details] [review]
0001-Move-to-current-GLib.patch

Created attachment 116888 [details] [review]
0002-Use-the-GLib-2.38-private-instance-data-system.patch

Comment on attachment 116887 [details] [review]
0001-Move-to-current-GLib.patch

Review of attachment 116887 [details] [review]:
-----------------------------------------------------------------

::: configure.ac
@@ -126,5 @@
>  AC_SUBST(GLIB_LIBS)
> -AC_DEFINE([GLIB_VERSION_MIN_REQUIRED], [GLIB_VERSION_2_30],
> -	[Avoid warning spew about g_type_init() being deprecated])
> -AC_DEFINE([GLIB_VERSION_MAX_ALLOWED], [G_ENCODE_VERSION(2,34)],
> -        [Notify us when we'll need to transition away from g_type_init()])

I think defining the MAX_ALLOWED is *very* useful - it avoids getting error spew from future deprecation warnings among other things.

I tend to version lock them - e.g. OSTree: https://git.gnome.org/browse/ostree/tree/Makefile.am#n24

Comment on attachment 116888 [details] [review]
0002-Use-the-GLib-2.38-private-instance-data-system.patch

Review of attachment 116888 [details] [review]:
-----------------------------------------------------------------

Looks reasonable to me.

(In reply to Colin Walters from comment #3)
> >  AC_SUBST(GLIB_LIBS)
> > -AC_DEFINE([GLIB_VERSION_MIN_REQUIRED], [GLIB_VERSION_2_30],
> > -	[Avoid warning spew about g_type_init() being deprecated])
> > -AC_DEFINE([GLIB_VERSION_MAX_ALLOWED], [G_ENCODE_VERSION(2,34)],
> > -        [Notify us when we'll need to transition away from g_type_init()])
> 
> I think defining the MAX_ALLOWED is *very* useful - it avoids getting error
> spew from future deprecation warnings among other things.
> 
> I tend to version lock them - e.g. OSTree:
> https://git.gnome.org/browse/ostree/tree/Makefile.am#n24

I guess we don’t want users to be worried by the deprecation warnings, but we should see them during development so that we update (at least assuming APIs are deprecated only for a good reason, which may not always be the case).

How about hooking this to AM_MAINTAINER_MODE?

(In reply to Miloslav Trmac from comment #5)

> How about hooking this to AM_MAINTAINER_MODE?

But what would a developer do about the deprecation when seeing the warning?  They can't update because of the maximum bound.  The only thing you can do is #ifdef GLIB_CHECK_VERSION() which makes sense in critical cases, but otherwise just adds significant pain.

At any point someone can say "let's look at increasing our minimum GLib bound", and see what warnings drop out of that, then fix up things.

There haven't really been many deprecations lately anyways.

What *has* landed in newer versions is https://bugzilla.gnome.org/show_bug.cgi?id=743640 and I find it hard to write C without it now.

> But what would a developer do about the deprecation when seeing the warning?  They can't update because of the maximum bound. 

Most importantly, that’s not what MAX_ALLOWED does. MAX_ALLOWED causes warnings about using functions _newly added_ after MAX_ALLOWED, that they are not available to the project; i.e. future versions of glib2 never add any new warnings to already existing functions based on MAX_ALLOWED AFAICT.

The deprecation warnings are entirely governed by MIN_REQUIRED.

MAX_ALLOWED documentation says
> Unless you are using GLIB_CHECK_VERSION() or the like to compile different code depending on the GLib version, then this should be set to the same value as GLIB_VERSION_MIN_REQUIRED.


---

Separately from the MAX_ALLOWED/MIN_REQUIRED difference, let’s assume that without MIN_REQUIRED we see new deprecation warnings with a new glib versino.

> But what would a developer do about the deprecation when seeing the warning?  They can't update because of the maximum bound. 

I don’t understand. What maximum bound? The patch removes the maximum bound macro.  We don’t currently have a defined project-wide maximum bound AFAICT; the removed comment

> -AC_DEFINE([GLIB_VERSION_MAX_ALLOWED], [G_ENCODE_VERSION(2,34)],
> -        [Notify us when we'll need to transition away from g_type_init()])

suggests that this was never a real bound but… I actually don’t know; #63440 doesn’t say in detail, and the only way this makes any sense to me is to expect that glib > 2.34 would completely remove g_type_init(), breaking ABI, and that we would need to update polkit for that.


More to the point, if a new deprecation warning appears, preferably we just update the code to the new variant. If the new variant is really unavailable in some glib version we care about, _then_ we can either reintroduce the minimum bound (with a good reason) or just locally use G_GNUC_BEGIN_IGNORE_DEPRECATIONS.

Created attachment 132121 [details] [review]
0001-Move-to-current-GLib.patch

pushing attachment 132121 [details] [review] now

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/polkit/polkit/issues/58.