For deeper dependencies like this, you really want to make sure the package or derivations are building as you expect before you try to add them to your system. For keyboard stuff, there are wierd workflow requirements – sometimes you may need to restart X11, sometimes you don’t; you can’t easily test everything. There are things like that here (and with the QEMU package) that make it tough to do all at once.
I’m not sure which parts your aware of here, so I tried to include everything anyways. Create a directory tree somewhere that looks like this:
echo "tmp-guix-modules/folaht/folaht/packages/xkb.scm" | tree --fromfile .
.
└── tmp-guix-modules
└── folaht
└── folaht
└── packages
└── xkb.scm
I named it as tmp-something because you’ll probably change how you structure the files as you learn more. I follow the directory structure in the guix codebase bc it’s just easier. they probably made better design decisions.
Including two ./fohlat/folaht levels gives you one extra layer of modules: you could have two or more separate guile module roots inside the same project. That was important for me later on when using the ares repl. Many channels do place them at the root, as do most scheme projects.
Then add the scheme module below into xkb.scm. once that’s complete, you should be able to run Guix commands. Using define-module below is a little heavier – it requires the directory tree for guile modules. Writing scripts starting with use-modules is a bit lighter, but requires a bit more CLI scripting. You have to know more about Guile’s module system.
mkdir -p tmp-guix-modules/folaht/folaht/packages; cd tmp-guix-modules
# edit ./folaht/folaht/packages/xkb.scm
guix build -L ./folaht --keep-failed xkeyboard-config-yr
# when a build fails, check the /tmp path. guix keeps it there
Once it succeeds:
guix shell -L ./folaht xkeyboard-config-yr
ls -al $GUIX_ENVIRONMENT # here's the package derivation root
tree -d -L2 $GUIX_ENVIRONMENT # here's the directory tree
Look around and check it out. Here’s the xkb.scm source
;; if you're still using (use-modules ...) at the top, this needs to be in a
;; module declared like below
(define-module (fohlat packages xkb)
you’ll almost certainly need these modules for guix functionality
#:use-module ((guix licenses) #:prefix license:)
#:use-module (guix gexp)
#:use-module (guix utils)
#:use-module (guix download)
#:use-module (guix git-download)
#:use-module (guix packages)
And these modules for package dependencies
#:use-module (gnu packages)
#:use-module (gnu packages freedesktop)
#:use-module (gnu packages xdisorg)
#:use-module (gnu packages pkg-config)
;; occasionally you'll need srfi-n modules. you almost always want srfi-1
#:use-module (srfi srfi-1)
This module gives you the (pretty-print “some scheme thing”)` function which can help debugging a ton. It probably won’t be available inside “G-expressions” though, once you get to those.
#:use-module (ice-9 pretty-print)
)
You almost always remove the pretty-print module and lines before committing. It’s a bit slow, but it’s easier to use early on… The output will appear in the logs.
Now that the module is declared, public symbols inside it can be made available to other guile scheme modules. The -L ./fohlat option to guix commands makes Guix aware of the modules in that directory tree. The modules must be named according to the directory structure.
;; symbols must be public or guix won't interpret them as packages
;; that can be installed from the CLI
(define-public xkeyboard-config-yr
(package
(inherit xkeyboard-config)
(source
(origin
(inherit (package-source xkeyboard-config))
(patches (list xkeyboard-config-yr-patch))))))
Many applications will read evdev.xml. how they handle errors depends on what dependencies read it (usually it’s compiled in; these days its libxkbcommon). For me, hyprland will freak out a little if it goes to query the evdev.xml database and can’t read it. The built-in dependency libxkbcommon then reads the RMVLO and KcCGST (I think…).
RVMLO is the rules file format: the one with the ! lines. It’s really confusing. If you already know how to work with that and the KcCGST files (with the C-like syntax), then you’ll probably alright.
;; this is pulling in the patch. it seems that xkb's files should be patched correctly.
;;
;; xkb's directory tree conventions are very, very strict!
(define xkeyboard-config-yr-patch
(origin
(method url-fetch)
(uri "https://codeberg.org/folaht/xkeyboard-config-yr/src/branch/main/sxrs/xkeyboard-config-yr.patch")
(sha256 (base32 "1jn9zg7cqpmxbdisklbl8iblwy8q1wxhp5p2zav8vwmr94kjjci7"))))
since evdev.xml is not a generated file (old/bad design on X11’s part), then a patch is an easier way to deal with it. there may be other ways (idk). you actually may want to split the patch into two: one for added files only then a separate one for evdev.xml only. This won’t help right now though.