GNOME Bugzilla – Bug 558490
New policykit mechanism uses hard-coded gconf path
Last modified: 2018-08-17 13:55:55 UTC
gconf-defaults.c: result = g_strconcat ("xml:merged:", pwd->pw_dir, "/.gconf", NULL); gconf-defaults.c: dest_address = "xml:merged:/etc/gconf/gconf.xml.mandatory"; gconf-defaults.c: dest_address = "xml:merged:/etc/gconf/gconf.xml.system"; gconf-defaults.c: unset_in_db (mechanism,"xml:merged:/etc/gconf/gconf.xml.mandatory", Note the /etc/gconf which is quite bad. It should probably be $sysgconfdir. Also, I don't think /etc/gconf/gconf.xml.system is standard across distributions, so it should probably a configure option.
It probably makes sense to use xml:readonly:@sysgconfdir@/gconf.xml.defaults since it's what is used in gconf/default.path.in and add a comment to ./gconf/default.path.in about this. The alternative is to parse /etc/gconf/2/path and to take the first item in the final xml:readonly series of items.
Bug 558490 – New policykit mechanism uses hard-coded gconf path * gconf/default.path.in: Add the directory that is used by the defaults mechanism * defaults/Makefile.am: Define SYSGCONFDIR * defaults/gconf-defaults.c: Use SYSGCONFDIR instead of hardcoding /etc/gconf. Pointed out by Vincent Untz
(In reply to comment #2) > Bug 558490 – New policykit mechanism uses hard-coded gconf path > > * gconf/default.path.in: Add the directory that is used by the > defaults mechanism This is wrong, it should get reverted: xml:readonly:/etc/gconf/gconf.xml.system is used in the PK tools for default settings, and that's the role played by xml:readonly:/etc/gconf/gconf.xml.defaults. Your change just made xml:readonly:/etc/gconf/gconf.xml.system a new place for mandatory settings, fwiw. (I guess Fedora uses gconf.xml.system instead of gconf.xml.defaults, which explains why gconf.xml.system was originally used)
As far as I am concerned, gconf.xml.system and gconf.xml.defaults have clearly different roles. Defaults is for 'factory defaults'. System is for system-wide settings. You don't want factory defaults to override system-wide settings on a package update. But sure, if you want, revert it and I can patch it back in in the Fedora package.
Okay, I see your point. That's similar to what we have in openSUSE (except that we have different names for the directories): --- gconf/default.path.in +++ gconf/default.path.in @@ -25,8 +25,12 @@ # system-wide in this file. include @sysgconfdir@/2/local-defaults.path -# Finally, look at the systemwide defaults +# Then look at the systemwide customizations xml:readonly:@sysgconfdir@/gconf.xml.defaults +# Then check vendor preferences +xml:readonly:@sysgconfdir@/gconf.xml.vendor +# And finally look at the defaults defined by installed schemas +xml:readonly:@sysgconfdir@/gconf.xml.schemas So the fix would be to move xml:readonly:/etc/gconf/gconf.xml.system just before gconf.xml.defaults, to not make it a mandatory source. How does that sound?
gconf should probably ship a /etc/gconf/gconf.xml.system and associated entry in the path file. Note it's a little muddled because "factory defaults" have traditionally been pretty synonymous with "schema defaults" which only occupy the /schemas subtree of gconf.xml.defaults I don't think we want a Fedora specific set of hacks though...
interesting, opensuse has a separate one just for schemas. So if I'm reading this right, opensuse's gconf.xml.defaults is like Fedora's gconf.xml.system and Fedora's gconf.xml.defaults is like opensuse's gconf.xml.vendor and gconf.xml.schemas combined. We should probably standardize on one scheme and get it upstream.
Ray: right. FWIW, Ubuntu does like openSUSE. Except that they added gconf.xml.system after gconf.xml.defaults for some weird reason. (The other difference is that they use /var/lib/gconf/debian.defaults and /var/lib/gconf/defaults instead of gconf.xml.vendor and gconf.xml.schemas for openSUSE -- but that's just a naming difference, the semantic is the same) I guess Debian is like Ubuntu, except that they don't have gconf.xml.system yet (because they don't have GNOME 2.24).
Okay, so it seems like the consensus (with Fedora being odd ball) is we should have: 1) a source for pristine upstream schemas 2) a source for vendor changes (panel defaults, and any overrides to upstream schemas) 3) a source for system defaults The first two probably shouldn't go in /etc since they aren't something the sysadmin should be changing. Not sure if /var or /usr makes the most sense. Anyway, at a minimum we should fix the order of where gconf.xml.system is to not be broken. I'll do that now while we figure out what the right layout should be.
for the record, on Mandriva Linux, we are using gconf.xml.defaults gconf.xml.local-defaults gconf.xml.mandatory gconf.xml.local-mandatory where both local-defaults / local-mandatory are always created by GConf2 package and used by our configuration tools when some system wide settings are changed by administrators. I'm in favor of Ray proposal and I'd be happy to move our vendor changes (which are currently merged into upstream defaults in gconf.xml.defaults). using /usr might be problematic if /usr is shared across systems through nfs or when /usr is read-only on some system.
Is there any specific reason why gconf.xml.system has to live in /etc (again, hardcoded), regardless of $prefix? My whole GNOME lives in /usr/local, so I get the annoying "There is a problem with your configuration server. /usr/local/libexec/gconf-sanity-check-2 has exited with code 256." popup on each and every login. I'll attach a patch that fixes this problem for me.
Created attachment 130986 [details] [review] Patch to fix the annoying popup on login
that patch is fine, although before this bug finishes we're going to be shuffling things around.
*** Bug 598264 has been marked as a duplicate of this bug. ***
halfline: So does the patch still apply and makes sense, or should its status be moved to "needs-work"?
Comment on attachment 130986 [details] [review] Patch to fix the annoying popup on login it's fine, but not sufficient to close this bug. I've committed it.
GConf has been deprecated since 2011. GConf is not under active development anymore. Its codebase has been archived: https://gitlab.gnome.org/Archive/gconf/commits/master dconf and gsettings are its successors. See https://developer.gnome.org/gio/stable/ch34.html and https://developer.gnome.org/GSettings/ for porting info. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent + supported version of dconf/gsettings. Thanks!