[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25741: [PATCH 2/2] gnu: kbd: Add neo layout.
From: |
Ricardo Wurmus |
Subject: |
bug#25741: [PATCH 2/2] gnu: kbd: Add neo layout. |
Date: |
Fri, 28 Apr 2017 16:37:52 +0200 |
User-agent: |
mu4e 0.9.18; emacs 25.1.1 |
ng0 <address@hidden> writes:
> Would this still work as intended?
> kbd is a global package, part of the base.
This doesn’t matter. The question here is: does this piece of software
have a mechanism to override or augment the search path for keymaps.
Often this is done with environment variables. So I took the sources
and searched for “getenv”:
tar xf $(guix build kbd)
grep getenv -r kbd-*
Here’s what turned up:
[…]
kbd-2.0.4/src/libkeymap/analyze.l: if ((ev =
getenv("LOADKEYS_INCLUDE_PATH")) != NULL) {
kbd-2.0.4/src/libkeymap/analyze.c: if ((ev =
getenv("LOADKEYS_INCLUDE_PATH")) != NULL) {
kbd-2.0.4/src/loadkeys.c: if ((ev = getenv("LOADKEYS_KEYMAP_PATH")) !=
NULL) {
[…]
This might be useful.
> If I create a new
> package which inherits from kbd, and people have to explicitly
> add it to (packages) in (operating-system), it will colide with
> (kbd).
I don’t understand what you mean. Guix gives us programmatic control
over the package graph. It is easy to replace all instances of one
package with another package (see “package-input-rewriting”). In this
case that’s not even necessary; one can just take the “%base-packages”
list, delete “kbd” from it, and cons “my-custom-kbd” onto it.
However, none of this will be needed if you can augment the path where
kbd looks for keymaps.
> I feel like kbd doesn#t work this way
What makes you say this? I don’t see anything special about kbd, but
maybe I’m missing something here.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net