Arch Linux

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.

@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.

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.

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.

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.

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.