Hello,
so I tried to implement this and it does not seem to work.
See this package:
https://github.com/vojtapolasek/vojtux/tree/mate_shortcut_test/rpm/mate-shortcut-test
I built this package with fedpkg for Fedora 40.
Steps to reproduce:
1. build the package
2. Login to Fedora 40 box and run
dconf dump / | grep custom
with no output expected
3. install the mate-shortcut-test package
4. repeat step 2
5. reboot
6. repeat step 2
Results:
I don't get any output in step 4 and 6
Expected result:
I expect output at least in step 6.
Any idea what I am doing wrong?
Thank you,
Vojta
Dne 01. 11. 24 v 18:13 Leon Fauster via devel napsal(a):
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!
--
_______________________________________________
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
