Am 01.11.24 um 17:48 schrieb Michael Catanzaro:
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.
I got the big picture, now. Thank you for your time!
--
Leon
--
_______________________________________________
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
