Bug 91198 - [Patch] Update go keep up with GLib
Summary: [Patch] Update go keep up with GLib
Status: RESOLVED MOVED
Alias: None
Product: PolicyKit
Classification: Unclassified
Component: daemon (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: David Zeuthen (not reading bugmail)
QA Contact: David Zeuthen (not reading bugmail)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-02 18:15 UTC by Miloslav Trmac
Modified: 2018-08-20 21:38 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
0001-Move-to-current-GLib.patch (7.63 KB, patch)
2015-07-02 18:16 UTC, Miloslav Trmac
Details | Splinter Review
0002-Use-the-GLib-2.38-private-instance-data-system.patch (72.29 KB, patch)
2015-07-02 18:17 UTC, Miloslav Trmac
Details | Splinter Review
0001-Move-to-current-GLib.patch (7.80 KB, patch)
2017-06-21 20:26 UTC, Miloslav Trmac
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Miloslav Trmac 2015-07-02 18:15:49 UTC
This mainly drops g_type_init() calls, and starts using the 2.38 private instance data system.
Comment 1 Miloslav Trmac 2015-07-02 18:16:52 UTC
Created attachment 116887 [details] [review]
0001-Move-to-current-GLib.patch
Comment 2 Miloslav Trmac 2015-07-02 18:17:05 UTC
Created attachment 116888 [details] [review]
0002-Use-the-GLib-2.38-private-instance-data-system.patch
Comment 3 Colin Walters 2015-07-02 18:31:11 UTC
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 4 Colin Walters 2015-07-02 18:33:08 UTC
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.
Comment 5 Miloslav Trmac 2015-07-02 18:48:08 UTC
(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?
Comment 6 Colin Walters 2015-07-02 18:52:33 UTC
(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.
Comment 7 Miloslav Trmac 2017-02-21 17:50:02 UTC
> 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.
Comment 8 Miloslav Trmac 2017-06-21 20:26:52 UTC
Created attachment 132121 [details] [review]
0001-Move-to-current-GLib.patch
Comment 9 Ray Strode [halfline] 2018-04-03 18:31:38 UTC
pushing attachment 132121 [details] [review] now
Comment 10 GitLab Migration User 2018-08-20 21:38:37 UTC
-- 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.