And now, finally, eudev and upower are fixed! 
Dear eudev developers, It is not very convenient that libudev can only use /etc/udev/hwdb.bin or /lib/udev/hwdb.bin. For Guix, we would like that the hwdb.bin file would be compiled for every used ...
Part 2. was easy, I think.
Dear eudev developers, In Guix, every package is installed in a separate "/usr" prefix. For instance, eudev is installed in "/usr-a/" and upower in "/usr-b/" (except it’s actually "/gnu/store/xxx-e...
My plan is 3-fold:
1. Let udevadm hwdb --update search hwdb files according to a search path;
2. Let udevadm hwdb --update generate the compiled database in a command-line-configured location;
3. Let #libudev find the hwdb.bin database according to an environment variable.
1. has been submitted: https://github.com/eudev-project/eudev/pull/262
I now have to do the rest!
Dear eudev developers, It would be useful for a Guix package to let udevadm hwdb --update collect hwdb files from different places in the file system. Usually, this is done with a search path. Here...
#eudev upgrade would introduce an extensible database of devices, called "hwdb". When adding new devices, such as with upower, you are supposed to add them to /usr/lib/udev/hwdb.d/ and then run udevadm hwdb --update, to compile the database down to a hwdb.bin file.
However, this does not fit well the #guix way, where each package has its own ro-mounted /usr.
@sir: Indeed. Feels like a valid statement for quite some situations, even situations, not everyone will agree with, like this one:
For me, a software which causes so much #pain that other started writing alternatives, is #systemd.
Without systemd, nobody would have had to write or #fork #eudev, #elogind, docker-systemctl-replacement, #opentmpfiles (by #OpenRC), etc.
Nobody would have ever created #Devuan and we wouldn't need an externally hosted (!) #debian-init-diversity mailing list, etc.
Vivien (dentelle & numérique)
Uhuru
fredg
localhost(tech_mode=True)
Axel 🚴😷🐧🐪⌨ | #WeAreNatenom