GNOME Bugzilla – Bug 796320
Remove deprecated schema paths
Last modified: 2021-05-25 13:02:42 UTC
We've all been ignoring these glib-compile-schemas warnings for a while now: Warning: Schema “org.gnome.system.locale” has path “/system/locale/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated. Warning: Schema “org.gnome.system.proxy” has path “/system/proxy/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated. Warning: Schema “org.gnome.system.proxy.http” has path “/system/proxy/http/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated. Warning: Schema “org.gnome.system.proxy.https” has path “/system/proxy/https/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated. Warning: Schema “org.gnome.system.proxy.ftp” has path “/system/proxy/ftp/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated. Warning: Schema “org.gnome.system.proxy.socks” has path “/system/proxy/socks/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated. It's kind of a joke at this point. openSUSE even has a patch to disable these warnings. At some point, I realized that I'm responsible for the proxy settings, and that's almost all of them. So I want to change glib-networking to look at a different path instead. The most logical choice would be /org/gnome/system/proxy, or perhaps /org/gnome/desktop/proxy (anyone have a preference?). We'll also have to update gnome-control-center and libproxy (which I think should cover Firefox?). Any other third-party stuff using these settings will just need to deal. Deprecating a gsetting is a bit tricky. We don't want to lose the user's old settings. So we should provide a transition period here before removing the old setting, let's say from GNOME 3.28 (Ubuntu 18.04 LTS) to whatever version of GNOME will be in Ubuntu 20.04 (probably GNOME 3.36, which will be plenty long enough to take care of Debian stable users too, and since enterprise distros are rebasing GNOME more frequently now, covering Ubuntu should be sufficient for pretty much everyone). Then we can remove the old settings in two years, and the warnings will go away then. In the meantime, we can just change the description to say "DEPRECATED: This setting is deprecated and ignored." At least that's what we do for Epiphany settings. glib-networking, gnome-control-center, and libproxy would read the new settings first, then fall back to the old settings and copy them over to the new settings. If that all sounds too hard, we could just change the stupid paths now without any transition period. Users will just have to enter their proxy settings once again. That's probably not a big deal. When we remove the old settings, anything still using them will crash, but it's a transition and we'll just have to deal. At least there won't be any silent breakage. There is also the org.gnome.system.locale setting. I suggest we do something about this too, but since I don't control the code that reads that setting, that's not for me to decide.
Stuff using the settings properly that would require migration: glib-networking gnome-control-center gsettings-desktop-schemas libproxy Questionable cases that we also care about: totem gnome-software gnome-terminal sound-juicer evolution-data-server (It's almost certainly bad for these to be using the proxy settings directly since it means not respecting the user's choice of GProxyResolver and not respecting glib-networking's logic designed to choose the right GProxyResolver. E.g. you lose flatpak integration. And when running outside GNOME you should be looking at libproxy instead.) Other stuff in Debian that would require migration: mate-terminal selektor prey tilix chromium (and qtwebengine-opensource-src) netbeans (and libnb-platform18-java) firefox (and firefox-esr) pidgin gtkpod cinnamon-control-center thunderbird ukui-control-center morla eclipse-platform-team mate-control-center cinnamon Clearly the list is nonzero but it's hardly insurmountable. We just need to send some merge requests upstream and make sure the upstreams know that the settings are going away and attempting to access them will cause instant crash. Apps will migrate very quickly because instant crash. :)
*** Bug 786916 has been marked as a duplicate of this bug. ***
(In reply to Michael Catanzaro from comment #1) > (It's almost certainly bad for these to be using the proxy settings directly > since it means not respecting the user's choice of GProxyResolver and not > respecting glib-networking's logic designed to choose the right > GProxyResolver. E.g. you lose flatpak integration. (Specifically, you miss GProxyResolverPortal and thus won't be able to read these settings anyway inside flatpak unless you grant full read access to all of dconf, which we are trying to discourage because it is unsafe.)
(In reply to Michael Catanzaro from comment #1) > Questionable cases that we also care about: > > totem We're now using GProxyResolver directly to massage the proxy info into something that GStreamer elements can use: > sound-juicer Similar code to totem's could probably be used to coerce libmusicbrainz into using those proxies. Could you please file an issue about it?
Filed https://gitlab.gnome.org/GNOME/sound-juicer/issues/1 for sound-juicer.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/issues/ Thank you for your understanding and your help.
Let's move discussion to https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/issues/27.