Bug 1196544

Summary: gsettings API missing from glib2 package
Product: Red Hat Enterprise Linux 6 Reporter: Dominik 'Rathann' Mierzejewski <dominik>
Component: glib2Assignee: Colin Walters <walters>
Status: CLOSED CANTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.6   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-27 13:38:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.