On Fri, Nov 1 2024 at 05:13:49 PM +01:00:00, Leon Fauster via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Ok, thanks. Following questions arised here now: - An explanation, why its bad would bring some light into this.
Dconf is not the only possible GSettings backend. E.g. if your RPM gets used to build a Flatpak app, then dconf isn't used at all and your attempted settings change will be ineffective.
There's normally no reason for a packager to use a dconf override rather than a gsettings override, so no reason to consider messing with dconf.
- ibus.el9 package do package a dconf file + scriptlet (its here installed, didn't check the whole repo)
I see ibus in el9 is using %postun and %posttrans scriptlets to run dconf-update. Remember you can no longer assume that those will execute on the target system; e.g. for Silverblue or Kinoite, it will run on the server that builds the ostree image. If your scriptlet touches /etc or /var, the scriptlet is probably broken. And that's what ibus is doing unfortunately.
- I mainly use etc/dconf because locking is possible. gsettings override seem not to offer such feature, or does it?
Correct, but that's fine, right. Why would a *packager* want to prevent users from changing the value of a setting?
If a system administrator wants to prevent unprivileged users from touching a setting, then it's fine to use dconf to lock the setting. But why would a Fedora packager wish to do this?
- overrides should also be "committed" with ... or not? # glib-compile-schemas /usr/share/glib-2.0/schemas
Yes, but you don't need to do this manually. There is an RPM file trigger to handle it.
I only ask so that I can do the right thing, thanks ... BTW, two perspectives here: packaging in general, or for local customization via "custom rpm" or any other way of automation ...
For local customization, feel free to use dconf. Michael -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
