Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#66849 - [glib-networking] Make gsettings-desktop-schemas an optional dependency

Attached to Project: Arch Linux
Opened by Martin Sandsmark (sandsmark) - Sunday, 31 May 2020, 18:01 GMT
Last edited by David Thurstenson (thurstylark) - Friday, 25 March 2022, 23:22 GMT
Task Type General Gripe
Category Packages: Extra
Status Assigned
Assigned To Jan Alexander Steffens (heftig)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 5
Private No


gsettings-desktop-schemas is only required for the gnome integration module, which doesn't work outside of gnome. It even explicitly checks if `XDG_CURRENT_DESKTOP` is set to `GNOME` before enabling itself ( ->

I'm not sure if even an optional dependency is necessary, since the module assumes a full gnome session is enabled, so you might get weird behavior if you try to force-enabling it by setting XDG_CURRENT_DESKTOP manually and installing gsettings-desktop-schemas.

And gsettings-desktop-schemas pulls in a lot of weird stuff like fonts...
This task depends upon

Comment by Marcell Meszaros (MarsSeed) - Thursday, 24 March 2022, 08:06 GMT
This is a harmful request based on an unfounded theoretical grievance.

I've tried @sandsmark's AUR/[gsettings-desktop-schemas-dummy] package
(empty package defining a provides= field for gsettings-desktop-schemas)
and it wreaked havoc on my KDE Plasma desktop.

If anything, [gsettings-desktop-schemas] would need to be *added*
as *mandatory* dependency to at least the following packages:
* [xdg-desktop-portal]
* [kded]

Takeaway from my experience (see #Details at the end):

[gsettings-desktop-schemas] is an integral part of [gtk3], and
[gtk3] is a mandatory dependency or indirect dependency of:
* KDE [plasma-desktop] and [plasma-workspace]
* XDG [xdg-desktop-portal]

Reason is these listed system modules are tightly integrated with
GTK libraries, for good interoperability with GTK/GNOME applications.

## Details:
## Errors encountered on KDE Plasma without [gsettings-desktop-schemas]

KDE Plasma notification tray doesn't show any GTK or Qt(!) application icons.
KDE and Qt and GTK applications take much longer to start (+30/+60 seconds).

[kded] kded5 fails to autostart and dumps core again and again.
[xdg-desktop-portal] xdg-desktop-portal.service fails to autostart and dumps core repeatedly.

Also frequent, repeating journal entries:
(journald) Error: user@1000.service: Settings schema 'org.gnome.system.proxy' is not installed
(journald) Error: user@1000.service: Settings schema 'org.gnome.desktop.interface' is not installed
(journald) Error: systemd: Failed to start Portal service.
Comment by David Thurstenson (thurstylark) - Sunday, 10 April 2022, 05:10 GMT
@MarsSeed Your test case involves removing gsettings-desktop-schemas entirely, even for other packages that *do* require it, which is why you get errors for other packages.

The question is whether *this* package requires gsettings-desktop-schemas, which would need to be tested in an environment where glib-networking is installed, but *no other* installed package requires gsettings-desktop-schemas.

Since `pactree -sr glib-networking | grep gsettings-desktop-schemas` does not return any results, this may be possible, but as it is, your testing environment does not produce results that can be used to determine the validity of this request.
Comment by Marcell Meszaros (MarsSeed) - Sunday, 10 April 2022, 12:07 GMT
Arch has a default practice and culture of not defining every direct mandatory dependency if a dependency is both a direct and a transitive dependency.

As it is the de facto situation, making changes on the lowest levels of the dependency chains have unforeseen runtime consequences on the higher levels.

Guess Arch maintainers would be advised to discuss this situation and come up with policy refinements to better safeguard against unforeseen dependency-related breakage because of 'ghost' dependencies.

I know for one that Levente Polyak has expressed his personal view that he a least prefers to declare every direct dependency, even if a dependency is both a direct and a transitive one.

KDE and GTK integration is a notorious case in point which is in favor of Polyak's opinion.
Comment by Marcell Meszaros (MarsSeed) - Sunday, 10 April 2022, 12:21 GMT
Currently [gtk3] for example is not in any way a directly declared dependency of anything KDE or Qt related.

Yet if one would remove GTK3, the whole KDE Plasma desktop environment would refuse to start.

[gtk3] is roughly 10 levels away on the dependency tree from any KDE package. It means Arch has a practice of having a kind of unwritten "gentlemen's agreement" of assuming that the lowest levels of the direct dependency tree can be assumed on the highest levels of the tree as well.
Comment by Marcell Meszaros (MarsSeed) - Sunday, 10 April 2022, 12:21 GMT
Proposing to remove low level dependencies without extensive testing evidence is outright irresponsible and dangerous on Arch.

Please go ahead and remove [gsettings-desktop-schemas] from [glib-networking]'s dependencies and have it uninstalled.

People using KDE Plasma will surely complain that their DE is broken.

Or at the least add [gsettings-desktop-schemas] as direct dependency to [kded] (edit: pkgname not 'kded5')
and [xdg-desktop-portal] as my testing indicates as needed.

Then you can drop the former to the optional dependency level in [glib-networking]'s packaging.