Project

General

Profile

Housekeeping #3168

[eudev-systemd]: package dropped - still suggested on the wiki

nona - 7 months ago - . Updated 3 months ago.

Status:
open
Priority:
broken
Assignee:
% Done:

0%


Description

  • expected result:
    to install eudev-systemd
  • actual result:
    error: target not found: eudev-systemd

Related issues

Related to Packages - Bug #3157: [eudev] depends on hwids, which has been replaced by hwdatafixed

Actions
Related to Packages - Freedom Issue #3195: Consider providing eudev as an alternative to udevduplicate

Actions

History

#1

Updated by bill-auger 7 months ago

  • Assignee set to Megver83
  • Status changed from unconfirmed to confirmed

megver - are there still any special requirements (in place of 'eudev-systemd') for packaging on a nonsystemd host?

several wiki pages mention 'eudev'

packagers guide:

7.8 Compiling packages without Systemd

librechrooot uses systemd-nspawn for compiling in chroots. There are two ways to use it without Systemd: Notsystemd and chroot-nspawn.

7.8.1 Chroot-nspawn

Chroot-nspawn is a systemd-nspawn wrapper for chroot. It combines features from chroot and unshared. To use it, simply install eudev-systemd package.

  1. pacman -S eudev-systemd

Tip: If using eudev-openrc, you might want to install notsystemd using the --assume-installed eudev flag

install guide:

Note: we need udev-init-scripts to start eudev at boot. This is technically optional, but if missing will lead to unexpected issues
You also have a choice of udev implementations to set up hardware devices; but as with the init program, a fully adequate one ('eudev') is installed already with the OpenRC 'base' package group.
eudev (the base-openrc default): Gentoo's fork of udev

OpenRC (Français):

{{bc| pacman -S parabola-openrc eudev-base}}

OpenRC (Español):

...emplazar_Systemd_con_eudev_.28usuarios_avanzados.29 reemplazar Systemd por eudev] es altamente recomendado. > Reemplazar Systemd con eudev (usuarios avanzados)

#2

Updated by bill-auger 7 months ago

  • Subject changed from Maintainer's guide asks for eudev-systemd to [eudev-systemd]: package dropped - still suggested by the Maintainer's guide
#3

Updated by bill-auger 7 months ago

  • Assignee deleted (Megver83)
  • Subject changed from [eudev-systemd]: package dropped - still suggested by the Maintainer's guide to [eudev-systemd]: package dropped - still suggested on the wiki
#4

Updated by bill-auger 7 months ago

  • Priority changed from bug to broken
  • Assignee set to Megver83
  • Status changed from confirmed to open
  • Project changed from Packages to Documentation
  • Tracker changed from Bug to Housekeeping
#5

Updated by nona 7 months ago

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.

#6

Updated by bill-auger 7 months ago

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

#7

Updated by gap 7 months ago

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.

#8

Updated by bill-auger 7 months ago

  • Related to Bug #3157: [eudev] depends on hwids, which has been replaced by hwdata added
#9

Updated by gap 7 months ago

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.

#10

Updated by bill-auger 7 months ago

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

#11

Updated by gap 7 months ago

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

#12

Updated by Megver83 6 months ago

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.

#13

Updated by bill-auger 5 months ago

#14

Updated by Drag0nFly 3 months ago

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)

Also available in: Atom PDF