Hi Arun, Thank you for submitting a patch! I've been wanting something like this for a long time, so I'm very happy to see it. I'll test it out and let you know if it works for me. Arun Isaac writes: > diff --git a/gnu/packages/security-token.scm b/gnu/packages/security-token.scm > index 7fdcaaf1e..424f4626e 100644 > --- a/gnu/packages/security-token.scm > +++ b/gnu/packages/security-token.scm > > [...] > > @@ -169,13 +171,16 @@ the low-level development kit for the Yubico YubiKey authentication device.") > "1jc9ws5ra6v3plwraqixin0w0wfxj64drahrbkyrrwzghqjjc9ss")))) > (build-system gnu-build-system) > (arguments > - `(#:configure-flags '("--enable-usbdropdir=/var/lib/pcsc/drivers" > - "--disable-libsystemd"))) > + `(#:configure-flags > + (list (string-append "--enable-usbdropdir=" > + (assoc-ref %build-inputs "ccid") "/pcsc/drivers") > + "--disable-libsystemd"))) If someone was relying on the previous behavior (in which pcsc-lite would look in /var/lib/pcsc/drivers for drivers), this would break for them if they were using anything other than the ccid drivers, right? However, I understand that previous Guix email threads have talked about adding a symlink there which points to ccid's drivers (I do that today, myself), so I can see why you would want to make this change. > @@ -186,6 +191,16 @@ from a client application and provide access to the desired reader.") > license:isc ; src/strlcat.c src/strlcpy.c > license:gpl3+)))) ; src/spy/* > > +(define pcsc-lite-bootstrap > + (package > + (inherit pcsc-lite) > + (name "pcsc-lite-bootstrap") > + (inputs > + `(("libudev" ,eudev))) > + (arguments > + (substitute-keyword-arguments (package-arguments pcsc-lite) > + ((#:configure-flags _) '(list "--disable-libsystemd")))))) > + What problem does this pcsc-lite-bootstrap package solve? It looks like you added pcsc-lite-bootstrap in order to avoid a cyclic dependency between ccid and pcsc-lite. That seems fair, but is there any other reason that I'm missing? > Subject: [PATCH 2/2] gnu: services: Add pcscd service. Do you know what the intent behind the --enable-usbdropdir option is in (1) the pcsc-lite configure script and (2) the ccid configure script? I checked the README in the source for both of these packages, but I couldn't quite understand the intended use. It wasn't clear to me if the usbdropdir directory is where the ccid/pcsc-lite expect to _find_ drivers that the user makes available, or if this directory is where the packages will _install_ their own drivers (or both, perhaps). If the usbdropdir is intended to house additional drivers that the user can "drop" in and use at runtime, then users of pcsc-lite/ccid might reasonably expect to be able to easily add additional drivers to the default configuration. If that's the case, then we might want to think about how we can give a user the ability to configure additional drivers. For example, if we gave the pcsc service configuration a field like "usbdropdir-drivers" (e.g. a list of packages or file-like objects), we could arrange for the union of those drivers to be placed into the usbdropdir for pcsc/ccid to use. Of course, I might be totally misunderstanding the intended use of the --enable-usbdropdir configuration option. If that's the case, please let me know. What do you think? -- Chris