From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 28 10:37:59 2017 Received: (at 25741) by debbugs.gnu.org; 28 Apr 2017 14:38:00 +0000 Received: from localhost ([127.0.0.1]:44836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d471z-0007Qh-NS for submit@debbugs.gnu.org; Fri, 28 Apr 2017 10:37:59 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d471x-0007QZ-Dy for 25741@debbugs.gnu.org; Fri, 28 Apr 2017 10:37:57 -0400 Received: from localhost (port-92-200-17-209.dynamic.qsc.de [92.200.17.209]) by mx.zohomail.com with SMTPS id 1493390274936823.9399796742642; Fri, 28 Apr 2017 07:37:54 -0700 (PDT) References: <20170215164800.15907-1-contact.ng0@cryptolab.net> <20170215164800.15907-2-contact.ng0@cryptolab.net> <8737em3ov0.fsf@elephly.net> <20170427215337.smsuh3jkuq7gw2ua@abyayala> <87d1bxarj4.fsf@elephly.net> <20170428093940.qebl5oexqszdblw3@abyayala> User-agent: mu4e 0.9.18; emacs 25.1.1 From: Ricardo Wurmus To: ng0 Subject: Re: bug#25741: [PATCH 2/2] gnu: kbd: Add neo layout. In-reply-to: <20170428093940.qebl5oexqszdblw3@abyayala> X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Date: Fri, 28 Apr 2017 16:37:52 +0200 Message-ID: <87bmrgy4vz.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 25741 Cc: 25741@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) ng0 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