So, when I ran sudo pacman -Syu (or yay -Syu) I got an error right at the end which said there was a conflict and the upgrade was abandoned.
It said: xkeyboard-config: /usr/share/X11/xkb exists in filesystem.
I had a hunch as to why this was happening. I had added a custom keyboard mapping file inside /usr/share/X11/xkb/symbols.
I tried again after moving that file out and it worked without issues. And then I moved the file back.
2 questions:
Why did this happen? Is it because the directory contents didn’t match with the new one?
Looks like you did exactly the same I did: I modified my German E2 keyboard settings /usr/share/X11/xkb/symbols/de to use the <> key as a level 5 instead level 3 shift, and a few days ago Pacman complained with exact your error message.
I was pretty impressed that it seems to “know” that changes were made (maybe it keeps checksums somewehere? Or was it just the backup file I made?).
Long story short: I copied my changed /usr/share/X11/xkb/symbols/de, put the backup /usr/share/X11/xkb/symbols/de.bak in its place again, and re-updated—success!
Of course I then replaced the file again against my changed one, rebooted, and all is back as intended,
I also wonder
why this happened (seems a good safety feature), and
how to do such a change correctly (and permanently)
Maybe someone more knowledgeable here can shed some light on this, for both of us.
Ah, great! Wasn’t aware that ~/.config/xkb would work for X11 stuff, too! (Maybe it is actually ~/.config/X11/xkb?) Thanks a lot! We’d just put the changed files there, right?
You do not need to.
If undefined it uses the listed paths.
But if you really wanted to set a variable you could again use either ~/.config/environment.d/* or /etc/environment - depending on if it is acceptable as an env var loaded by user or globally.
KEY=VALUE is the accepted syntax in the file.
Considering the reply below yours and what you may be trying to do then maybe /etc/ in the way to go.
Furthermore I might mention you probably do not want to set XKB_CONFIG_ROOT .. if a custom path is desired for any it would likely be best to use XDG_CONFIG_EXTRA_PATH, ie something like: XDG_CONFIG_EXTRA_PATH=/etc/mycustompath or similar.