bug#25741: [PATCH 2/2] gnu: kbd: Add neo layout.

[Ricardo Wurmus <rekado@elephly.net>]

ng0 <contact.ng0@cryptolab.net> 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