Bug 1196544 - gsettings API missing from glib2 package
Summary: gsettings API missing from glib2 package
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glib2
Version: 6.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Colin Walters
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-26 08:53 UTC by Dominik 'Rathann' Mierzejewski
Modified: 2015-02-27 13:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-27 13:38:18 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Dominik 'Rathann' Mierzejewski 2015-02-26 08:53:40 UTC
Description of problem:
gio-2.0 API is detected - pkgconfig claims it's there, but the gsettings API is missing in the glib2 package and latexila doesn't build because of that.

Version-Release number of selected component (if applicable):
glib2-2.28.8-4.el6

How reproducible:
Always.

Steps to Reproduce:
1. Try to build latexila-1.99.1

Actual results:
[...]
-- checking for module 'gio-2.0 >= 2.25.10'
--   found gio-2.0 , version 2.28.8
[...]
/builddir/build/BUILD/latexila-1.99.1/src/preferences_dialog.c: In function '_lambda2_':
/builddir/build/BUILD/latexila-1.99.1/src/preferences_dialog.c:192: warning: implicit declaration of function 'g_settings_set_string'
[...]
/builddir/build/BUILD/latexila-1.99.1/src/preferences_dialog.c:402: error: 'G_SETTINGS_BIND_GET' undeclared (first use in this function)

Expected results:
gsettings API should be present.

Additional info:
Looks like it was removed in December 2013 based on bug 1035941, which I don't have access to. If you don't want to re-add it (as a subpackage perhaps), then I'd like to re-introduce it through EPEL.

Comment 1 Dominik 'Rathann' Mierzejewski 2015-02-26 10:06:17 UTC
Looking at what your patch to remove gsettings does, you're changing library behaviour and actually removing code, so this can't be packages separately as an add-on package. Please restore.

Comment 2 Colin Walters 2015-02-26 14:30:02 UTC
The origin bug is https://bugzilla.redhat.com/show_bug.cgi?id=1036097

Basically OpenJDK is conflating the existence of the "g_settings_new" symbol with the existence of gsettings-desktop-schemas (which is understandable, but unfortunate).

So we can't introduce the GSettings API without introducing gsettings-desktop-schemas, which drags in yet more stuff.

I understand that this breaks application version checks, but if you're building such an app for RHEL6, I think you'll have to carry a patch to the app to disable the gsettings code.

Comment 3 Dominik 'Rathann' Mierzejewski 2015-02-26 17:51:35 UTC
Why don't you fix the bug in OpenJDK package, then, instead of ripping out code from glib2 to work around it? Is there a publicly accessible bug against OpenJDK about this? It's wrong to claim gio-2.0 is available but then break compilation of third party code by removing APIs from it.

Comment 4 Dominik 'Rathann' Mierzejewski 2015-02-26 18:11:16 UTC
I guess it's this: https://bugs.archlinux.org/task/26531 . I'm not sure if the bug is in OpenJDK and other consumers of this API or in glib2, but if the SIGSEGV occurs in glib2, then perhaps it should be fixed there.

Also, http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17118 .

Comment 6 Colin Walters 2015-02-26 20:21:23 UTC
Technically any application that wants proxy settings should require gsettings-desktop-schemas.

glib2 can be used without schemas too, that's why it doesn't depend on it.  (glib-networking however does).

So this bug originated with bringing a newer glib2 for a newer Evolution, and it was certainly unforseen that old versions of OpenJDK used the presence of the g_settings() API to mean that gsettings-desktop-schemas was installed.

A crosscutting concern was that up until relatively recently, the JDK was not modularized, so it pretty much always pulled in desktop infrastructure.

So again, I completely understand your concerns here, but we can't back out now, so RHEL6 applications will need to deal with it.  I don't think the subpackage approach is going to be feasible, but I welcome more suggestions or patches.

Comment 7 Colin Walters 2015-02-27 13:38:18 UTC
I'm going to close this as CANTFIX - representing the current state.  But Bugzilla states aren't final - anyone should feel free to add ideas, and if we agree it's possible to implement, this bug can be reopened.


Note You need to log in before you can comment on or make changes to this bug.