Hi Brice, Ludo, On +2020-04-06 07:54:47 +0000, Brice Waegeneire wrote: > Hello Ludo', > > On 2020-04-05 21:15, Ludovic Courtès wrote: > > guix-comm...@gnu.org skribis: > > > #~(begin > > > (setenv "LINUX_MODULE_DIRECTORY" > > > "/run/booted-system/kernel/lib/modules") > > > + ;; FIXME: Remove this crutch when the patch > > > #40422, > > > + ;; updating to kmod 27 is merged. > > > + (setenv "MODPROBE_OPTIONS" > > > + "-C /etc/modprobe.d") > > > > [...] > > > > > + (services (cons* (service kernel-module-loader-service-type > > > + '("ddcci" "ddcci_backlight")) > > > + (simple-service 'ddcci-config etc-service-type > > > + (list `("modprobe.d/ddcci.conf" > > > + ,ddcci-config))) > > > + %base-services)) > > > > Looking at this, I was wondering if it would be possible to not use > > /etc/modprobe.d and instead have a way to tell the modprobe wrapper to > > pass “-C /gnu/store/…-modprobe.d”, which would contain the right thing. > > > > Thoughts? > > What's the issue with using /etc/modrpobe.d? >
I would think the fundamental issue is pure vs impure dependencies: i.e., /gnu/... vs /var/guix vs /elsewhere/... IIUC, the consequence of using /etc/... or ~/... or other non-/gnu/... is that if you want to run something in a container with chrooted root, you have to cow-fake /etc and all the rest of non-/gnu/... environment, so your executable is not as generally usable as possible if nuisance adjustments were not necessary. People who might want to use it anyway have to think about a bunch of stuff not relevant to what they actually want to do -- they will wind up debugging functionally-irrelevant implementation stuff. Maybe I misunderstand, but are you and Ludo on the same page re the fundamental concept of guix and how it plays in various contexts? (allowing for "practicality beats purity"[1] when absolutely necessary ;-) > As noted in the comments I thought setting MODPROBE_OPTIONS was kinda of a > hack; #40422[0] was there to fix it. But if you think it's appropriate to > use this environment variable it can be done in a future > “kernel-module-configuration-service-type” we discussed with Danny[1]. > Instead of extending “etc-service-type” we would use > “activation-service-type”, as “%modprobe-wrapper” is currently put > in place by a simple activation service. > > [0]: https://issues.guix.info/issue/40422 > [1]: https://issues.guix.info/issue/40274#29 > > - Brice > [1] python -c 'import this' -- Regards, Bengt Richter