Thank you, bill. In the mean time, eudev has replaced eudev-systemd in the English wiki. I will try to see if everything goes well with my packaging attempts.

there is no 'eudev' package - it was replaced by 'udev' - i suppose that the wiki should suggest 'udev' instead - 'eudev' could be removed from 'udev' provides, at some later time - it's entire role to parabola was as an alternate/interchangeable provider of 'udev'

`pacman -S eudev` works now because the 'udev' package provides 'eudev' - that is something of a kludge to ease migration - the 'eudev' package provided 'udev' - any other packages should depend on 'udev'; so all mentions of 'eudev' could go away soon

OTOH, some people want to restore 'eudev' - i suppose that is another possibility; but we should decide whatever, before the wiki gets confusing/outdated

Related to #3155 and #3157.

AFAICT Gentoo deprecated `eudev` in favour of directly using `udev` from systemd, after which it was revived by other contributors.
I don't think switching to `udev` is the best course of action, when we can adopt the revived `eudev` at https://github.com/eudev-project/eudev instead; `eudev` seems to be committed to supporting different init systems, whereas the systemd project is well-known for its all-encompassing design; moreover, there are many loose ends that would have to be tied up such as the wiki and installation instructions, if we were to make the switch to `udev`.

In a nutshell, I'm not convinced on the rationale for switching to `udev`, which seems to be based purely on the fact that the original `eudev` project was deprecated, which isn't an issue since it's all free software and another team have already revived it.
I think we would be introducing unnecessary breakages and potentially more pain in the long run as we might have to switch back to `eudev` after systemd becomes even more hostile to other init systems in the future.

Please may I ask what decision we are making, or at least bump the thread?
This decision is important because `udev`/`eudev` is a system component and any changes we make have the potential to send ripples out across the entire system.

the changes have already been made - it caused no problem because
eudev was but one generic "provider" of the essential
requirement: "some (any) udev implementation" - it would be a
problem, only if there were no package providing a udev
implementation - any more than one, are interchangeable
alternatives

i suppose the decision is between:

A) restore eudev as an alternate udev
B) remove mentions of eudev from the wiki

I vote for option A because this compromise allows each user to pick his or her own `udev` implementation.

eudev is systemd's udev, and it is almost exactly the same as nonsystemd/udev, please don't bring eudev back, it is pointless.

I'll check and update the wiki pages ASAP, I haven't touched my PC for a while, too busy, but will make some time to fix this issue correctly.

I also vote for option A; eudev was forked specifically to isolate udev from any specific init system, and to avoid inherent bloat from saturating other components. This control over ones freedom was my primary reason for choosing Parabola, a distro which I've later installed on all my systems.

In the meantime I've packaged the 3.2.11 version of eudev on my own, making it dependent on hwdata instead of hwids. However, the system still tries to pull in the systemd-provided udev. Not sure if this is due to “udev=243” being provided by eudev or something else in the package dependency list.

warning: ignoring package replacement (eudev-3.2.11-9 => udev-250.2-1)

To my knowledge, the systemd-provided udev also has a different way of enumerating network devices, despite the presence of 80-net-name-slot.rules -> /dev/null in /etc/udev/rules.d (which maintains eth[n] notation instead of driver-specific names, possibly due to missing the “--enable-rule-generator” compilation option)