The eudev maintainer blueness indicated that they are no longer interested in maintaining eudev. They asked us if we want to take over maintainership:
blueness │ hi ncopa et al. Does anyone want to take over maintenance of eudev? I'm going to give it up since gentoo/musl is moving to systemd+openembedded patches | it only has a few bugs, but is lagging behind upstream
So we can do 3 things
Take over maintainership
Drop it and switch to an alternative (libudev-zero)
Leave it, hope someone else takes over
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Would be nice to see if libudev-zero could be a possible replacement. Not sure it has all the interfaces/tools to be drop in. There has been some discussion about it on #alpine-devel regarding hotplugging and related.
FWIW, Gentoo is not planning to drop OpenRC (and with it standalone udev) as an init system option, at least for the foreseeable future. (I'm building the musl stages for x86(-64) there in releng.) To my knowledge our plan is to switch to (systemd-)udev with the relevant parts of the openembedded patches.
fyi, on my systems libudev-zero works fine for most 'things', even Xorg hot plugged input devices are recognized and works fine. Only package I know that need fix is usb-modeswitch-udev
Hmm, I’m currently installing Alpine on my new notebook (Sway-based desktop) in a ”hard way”, learning desktop-specific stuff and fixing/optimizing packages on the fly, so I’ll try replacing eudev with libudev-zero and report back.
Maybe I should also note: I use mdev on all of my servers (physical or virtual), I’ve never needed eudev for the server use case. That’s why I somehow implicitly assumed the desktop-like use case for eudev.
Maybe I should also note: I use mdev on all of my servers (physical or virtual), I’ve never needed eudev for the server use case. That’s why I somehow implicitly assumed the desktop-like use case for eudev.
The TSC prefer libudev-zero as the long-term solution. Due to concerns over its maturity, the TSC decided to investigate Gentoo's approach in parallel to the adoption of libudev-zero.