How do you manage your /dev

[sam_]

No, it's not a Gentoo issue. I suggest reading the viewtopic-t-1164332-highlight-.html thread again.

[pjp]

USE="udev" systemd-utils is udev.
Udev is part of systemd that is extracted by the gentoo devs as a standalone package.

Most people are too shy to comment.

Based on the prior quote, I didn't find it worth mentioning. I disagree with your assertion that udev + systemd-utils = udev.

I've masked sys-fs/eudev, likely due to it's original deprecation by Gentoo, or possibly by the state of it's maintenance within Gentoo. I don't recall which. Also masked is sys-fs/udev, but I don't know why. I don't see me having an active mask for it. I don't see an mdev in ::gentoo, so I'm not certain what it is, although it sounds familiar. If it's not in ::gentoo, that's why I'm not using. I do see a dev-libs/libsmdev in ::pentoo, but I normally don't install libraries by themselves. In addition, I have a mask on sys-apps/systemd (and kin).

What I do have installed are sys-apps/systemd-utils, sys-fs/udev-init-scripts, virtual/udev, and virtual/libudev. So the whole "udev / systemd" arrangement seems like a mess. As I don't have sys-fs/udev installed, it appears that my "Something else" choice is correct.

So it is a gentoo issue.

I think the issue has always been no Gentoo developers or users being willing or able to maintain it. Originally the package in it's entirety, but now apparently even maintaining the ebuild. This seems to be a common pattern for various packages, but for semi-obvious reasons, it is mostly seen among those choosing to not use systemd and related software. I include myself among them, but I don't have the skills to do the dev work, so at best I could only do testing. And I'm averse to having my primary systems unavailable, so I'd need to sort out a development environment (which has its own problems). It was roughly around the time Gentoo dropped support for libressl that I admitted to myself that offering "constructive complaints" wasn't useful to anyone, so I try to avoid offering it. It was probably a while before that when I lost most of my interest in, to borrow a phrase, "faffing about" with OSes. I now try to stick with mainstream ::gentoo with few exceptions.

When it was first announced that Gentoo was going to drop eudev, some stepped forward to maintain it. Maybe there are some Gentoo eudev users who are able and willing to do that again.

EDIT:

I didn't see sam_'s post, so I guess it isn't an issue with available development effort.

[stefan11111]

I disagree with your assertion that udev + systemd-utils = udev.

$ eselect news read 19
2022-04-19-systemd-utils
Title Migration to sys-apps/systemd-utils
Author Mike Gilbert <floppym@gentoo.org>
Posted 2022-04-19
Revision 1

The sys-apps/systemd-utils package was recently added to the gentoo
repository. This replaces sys-apps/systemd-tmpfiles,
sys-boot/systemd-boot, and sys-fs/udev with a single package, and is
for OpenRC users. It does not depend on sys-apps/systemd and contains
the same exact components as the split packages.

USE flags are provided to allow each component to be enabled
or disabled. This change was made to significantly ease maintenance of tools
split out from systemd.

When upgrading to sys-apps/systemd-tmpfiles-250,
sys-apps/systemd-utils[tmpfiles] will be pulled in as a dependency.

When upgrading to sys-boot/systemd-boot-250,
sys-apps/systemd-utils[boot] will be pulled in as a dependency.

When upgrading to sys-fs/udev-250, sys-apps/systemd-utils[udev] will be
pulled in as a dependency.

At a later date, sys-apps/systemd-tmpfiles, sys-boot/systemd-boot, and
sys-fs/udev will be masked for removal once a suitable version of
sys-apps/systemd-utils has been marked stable and sufficient time has
been provided for users to migrate.

Possible problems when upgrading:

1. If sys-fs/eudev is present in the world file (@selected), emerge will
abort the upgrade with a unsolvable blocker error. To resolve this,
either remove sys-fs/eudev from the world file
(emerge --deselect sys-fs/eudev), or disable the 'udev' USE flag for
sys-apps/systemd-utils.

2. The 'boot' USE flag on sys-apps/systemd-utils is disabled by default.
Users migrating from sys-boot/systemd-boot will need to enable the
'boot' USE flag (in package.use) to continue receiving updates.

3. If you have package.use entries for any of sys-apps/systemd-tmpfiles,
sys-boot/systemd-boot, or sys-fs/udev, please update the relevant lines
to refer to sys-apps/systemd-utils instead. This might include
ABI_X86_32 for some users!

I don't see an mdev in ::gentoo, so I'm not certain what it is, although it sounds familiar. If it's not in ::gentoo, that's why I'm not using.

It's USE="mdev" sys-apps/busybox

[Syl20]

It's USE="mdev" sys-apps/busybox

As this choice had 0 hits, I made it. That's how I manage /dev on my servers, and they work well.
On my stations... well... However I take the problem, because of my devices (HP printers and scanner, network cards...) and how I use them, I do need a working libudev library.
But, as long as I could resist against systemd stuff, I will do. So, my stations still run eudev, even if it's been (re)masked now. For how much time ?

Sometimes updates become a headache (and sometimes that makes me angry and uselessly aggressive. Again, sorry maintainers)... Today, I got trouble with the eudev package _and_ USE flag masks. This kind of annoyance seems more and more current to me, and that makes me wonder if, in the end, definitely stopping updating my systems would be the best thing to do for my mental health.

[stefan11111]

It's USE="mdev" sys-apps/busybox

As this choice had 0 hits, I made it. That's how I manage /dev on my servers, and they work well.
On my stations... well... However I take the problem, because of my devices (HP printers and scanner, network cards...) and how I use them, I do need a working libudev library.
But, as long as I could resist against systemd stuff, I will do. So, my stations still run eudev, even if it's been (re)masked now. For how much time ?

Sometimes updates become a headache (and sometimes that makes me angry and uselessly aggressive. Again, sorry maintainers)... Today, I got trouble with the eudev package _and_ USE flag masks. This kind of annoyance seems more and more current to me, and that makes me wonder if, in the end, definitely stopping updating my systems would be the best thing to do for my mental health.

In the thread linked by sam_, you say that you need libudev. However, the thread is about a libgudev problem. You can disable udev where everywhere except where you really need it.

[Syl20]

I already made that :

Code: Select all

# grep -rE "USE|udev" /etc/portage
/etc/portage/package.mask/udev:sys-fs/udev
/etc/portage/package.mask/udev:=dev-libs/libgudev-238-r1
/etc/portage/profile/use.mask:-eudev
/etc/portage/package.unmask:sys-fs/eudev
/etc/portage/make.conf:USE="X a52 aac acpi alsa ao apng archive audio audiofile audit \
/etc/portage/make.conf:     dvdarchive dvdnav dvdr egl elogind encode eudev exif extensions extra \
/etc/portage/make.conf:     -thin -tls-heartbeat -udev -webkit -wext -zeroconf"
/etc/portage/package.use/xorg:x11-base/xorg-server      elogind udev
/etc/portage/package.use/eudev:sys-fs/eudev     static-libs
/etc/portage/package.use/libusb:virtual/libusb  udev
/etc/portage/package.use/libusb:dev-libs/libusb udev

But some packages don't have an appropriate USE flag.

Code: Select all

# equery d libudev
 * These packages depend on libudev:
app-text/calibre-5.44.0-r1 (udisks ? virtual/libudev)
dev-libs/libatasmart-0.19_p5 (virtual/libudev)
dev-libs/libgudev-237-r1 (>=virtual/libudev-199:0/1[abi_x86_64(-)])
dev-libs/libinput-1.23.0 (virtual/libudev)
dev-libs/libusb-1.0.26 (udev ? >=virtual/libudev-208[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
dev-qt/qtgui-5.15.10-r1 (udev ? virtual/libudev)
dev-qt/qtwebengine-5.15.10_p20230623 (virtual/libudev)
media-libs/libcanberra-0.30-r7 (udev ? virtual/libudev[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
media-libs/libsdl2-2.28.1 (udev ? >=virtual/libudev-208[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
media-libs/libv4l-1.22.1 (dvb ? virtual/libudev[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
media-plugins/gst-plugins-vaapi-1.20.6 (drm ? >=virtual/libudev-208[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
media-video/pipewire-0.3.77-r2 (virtual/libudev[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
net-misc/freerdp-2.10.0-r3 (usb ? virtual/libudev:0)
net-misc/networkmanager-1.42.6-r1 (>=virtual/libudev-175[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
sys-apps/pciutils-3.10.0 (udev ? >=virtual/libudev-208[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
sys-apps/usbutils-015 (virtual/libudev)
sys-apps/util-linux-2.38.1-r2 (udev ? virtual/libudev)
sys-auth/elogind-246.10-r3 (virtual/libudev)
sys-fs/cryptsetup-2.6.1 (udev ? virtual/libudev)
sys-fs/lvm2-2.03.21-r1 (udev ? virtual/libudev)
x11-base/xorg-server-21.1.8-r2 (udev ? virtual/libudev)
x11-drivers/xf86-video-intel-2.99.917_p20230201 (udev ? virtual/libudev)

[stefan11111]

Do equery d libgudev
Notice the extra g.

[Syl20]

Code: Select all

# equery d libgudev
 * These packages depend on libgudev:
gnome-base/gvfs-1.50.6 (udev ? >=dev-libs/libgudev-147)
gnome-extra/nm-applet-1.32.0 (>=dev-libs/libgudev-147)
media-gfx/gimp-2.10.34-r2 (udev ? dev-libs/libgudev)
media-libs/clutter-1.26.4-r1 (egl ? >=dev-libs/libgudev-136)
media-libs/clutter-gst-3.0.27-r2 (udev ? dev-libs/libgudev)
media-libs/gst-plugins-base-1.20.6 (gbm ? >=dev-libs/libgudev-147[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
media-plugins/gst-plugins-v4l2-1.20.6 (udev ? >=dev-libs/libgudev-208[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
net-libs/libqmi-1.30.8 (>=dev-libs/libgudev-232)
net-misc/modemmanager-1.18.12 (udev ? >=dev-libs/libgudev-232)
sys-fs/udisks-2.9.4-r3 (daemon ? >=dev-libs/libgudev-165)
sys-power/upower-0.99.20 (kernel_linux ? >=dev-libs/libgudev-236)
xfce-base/libxfce4ui-4.18.4 (system-info ? dev-libs/libgudev)
xfce-base/thunar-4.18.6 (udisks ? dev-libs/libgudev)
xfce-base/thunar-volman-4.18.0 (dev-libs/libgudev)

[stefan11111]

These are the ones that unconditionally need libgudev:

Code: Select all

gnome-extra/nm-applet-1.32.0 (>=dev-libs/libgudev-147)
net-libs/libqmi-1.30.8 (>=dev-libs/libgudev-232)
xfce-base/thunar-volman-4.18.0 (dev-libs/libgudev)

Do you need them?

[Syl20]

Do you need them?

Code: Select all

gnome-extra/nm-applet-1.32.0 (>=dev-libs/libgudev-147)

Yes. I often need to switch quickly from a network to another (this computer is a laptop).

Code: Select all

net-libs/libqmi-1.30.8 (>=dev-libs/libgudev-232)

Well... good question.

Code: Select all

# equery d libqmi
 * These packages depend on libqmi:
net-misc/modemmanager-1.18.12 (qmi ? >=net-libs/libqmi-1.30.8[qrtr?])
# equery -N u modemmanager|grep qmi
 + + qmi           : Enable support for the QMI modem protocol used by devices with Qualcomm chipsets

So, yes. I sometimes need an internet connection via my phone.

Code: Select all

xfce-base/thunar-volman-4.18.0 (dev-libs/libgudev)

I think no. But as there are two really needed packages above, I think I can wait before replacing this meta-package by its children one by one :

Code: Select all

 # equery d thunar-volman
 * These packages depend on thunar-volman:
xfce-base/xfce4-meta-4.18 (>=xfce-base/thunar-volman-4.18.0)

[stefan11111]

Do you need them?

Code: Select all

gnome-extra/nm-applet-1.32.0 (>=dev-libs/libgudev-147)

Yes. I often need to switch quickly from a network to another (this computer is a laptop).

Do you need network-manager, or that applet?

Code: Select all

net-libs/libqmi-1.30.8 (>=dev-libs/libgudev-232)

Well... good question.

Code: Select all

# equery d libqmi
 * These packages depend on libqmi:
net-misc/modemmanager-1.18.12 (qmi ? >=net-libs/libqmi-1.30.8[qrtr?])
# equery -N u modemmanager|grep qmi
 + + qmi           : Enable support for the QMI modem protocol used by devices with Qualcomm chipsets

So, yes. I sometimes need an internet connection via my phone.

You mean usb tethering? no need for that package. All usb tethering needs is kernel support.

Code: Select all

xfce-base/thunar-volman-4.18.0 (dev-libs/libgudev)

I think no. But as there are two really needed packages above, I think I can wait before replacing this meta-package by its children one by one :

Code: Select all

 # equery d thunar-volman
 * These packages depend on thunar-volman:
xfce-base/xfce4-meta-4.18 (>=xfce-base/thunar-volman-4.18.0)

You can just use package.provided if you prefer.

[Syl20]

Do you need network-manager, or that applet?

I need both. When I say I often need to switch _quickly_ from a network to another, that means "in two clicks".

You mean usb tethering? no need for that package. All usb tethering needs is kernel support.]

OK. Interresting. I'll do a try.

You can just use package.provided if you prefer.

You're right ! Thank you.

[NeddySeagoon]

stefan11111,

(e)udev and friends manage symlinks and permissions in /dev.
I don't think that requires /dev in the kernels DEVTMPFS.

Dynamic adding and removal of /dev entries is performed by the kernel. (e)udev does not add or delete /dev nodes.

Even with a static /dev, you can look in /sys/dev/* to see what dev nodes the kernel would have created and discover the major:minor device numbers.

[stefan11111]

Do you need network-manager, or that applet?

I need both. When I say I often need to switch _quickly_ from a network to another, that means "in two clicks".

Code: Select all

gnome-extra/nm-applet-1.32.0 (>=dev-libs/libgudev-147)

That really doesn't need the new libgudev. The libgudev in ::gentoo is at version 238. You just need >=147.
Add an older ebuild to your overlay and mask everything newer. You will also need old distfiles. See if Neddy or someone else has them and download them.

[stefan11111]

stefan11111,

(e)udev and friends manage symlinks and permissions in /dev.
I don't think that requires /dev in the kernels DEVTMPFS.

Dynamic adding and removal of /dev entries is performed by the kernel. (e)udev does not add or delete /dev nodes.

Even with a static /dev, you can look in /sys/dev/* to see what dev nodes the kernel would have created and discover the major:minor device numbers.

AFAIK, the (e)udev init scripts stop the boot process if DEVTMPFS isn't in use.

[Syl20]

That really doesn't need the new libgudev.

Of course not.

Add an older ebuild to your overlay and mask everything newer.

Already done.

[stefan11111]

That really doesn't need the new libgudev.

Of course not.

Add an older ebuild to your overlay and mask everything newer.

Already done.

In that case, your problem is solved, isn't it?

[Syl20]

I don't think so. At the beginning, the problem is not libgudev (with the "g"). The problem is that more and more basic components depend on a working libudev (without the "g"), and the lonely gentoo package that provides it today is the systemd-ized version.
That said, thank you to help me to sanitize my system.

[pjp]

$ eselect news read 19
2022-04-19-systemd-utils

One thing we can agree on, that is a news item from 2022. I expected a response of that kind or similar, which is why I didn't originally respond after selecting "Something else."

[stefan11111]

I don't think so. At the beginning, the problem is not libgudev (with the "g"). The problem is that more and more basic components depend on a working libudev (without the "g"), and the lonely gentoo package that provides it today is the systemd-ized version.
That said, thank you to help me to sanitize my system.

It that case, let's take a look at libudev too.
Here, I have no such things:

Code: Select all

$ eix -I udev
No matches found

These are the packages that must have libudev. Do you really need all of them?

Code: Select all

dev-libs/libatasmart-0.19_p5 (virtual/libudev)
dev-libs/libgudev-237-r1 (>=virtual/libudev-199:0/1[abi_x86_64(-)])
dev-libs/libinput-1.23.0 (virtual/libudev)
dev-qt/qtwebengine-5.15.10_p20230623 (virtual/libudev)
media-video/pipewire-0.3.77-r2 (virtual/libudev[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
net-misc/networkmanager-1.42.6-r1 (>=virtual/libudev-175[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
sys-apps/usbutils-015 (virtual/libudev)
sys-auth/elogind-246.10-r3 (virtual/libudev)

I understand that you must use networkmanager, which needs libudev, and it's gui needs libgudev.
What do you need pipewire for?
What do you need elogind for?
What do you need libinput for?
What do you need qtwebengine for?
What do you need usbutils for?
What do you need libatasmart for?

[stefan11111]

$ eselect news read 19
2022-04-19-systemd-utils

One thing we can agree on, that is a news item from 2022. I expected a response of that kind or similar, which is why I didn't originally respond after selecting "Something else."

Did anything change since 2022 in regards to this?

[Syl20]

I understand that you must use networkmanager, which needs libudev, and it's gui needs libgudev.
What do you need pipewire for?
What do you need elogind for?
What do you need libinput for?
What do you need qtwebengine for?
What do you need usbutils for?
What do you need libatasmart for?

Seriously ? Do you really want me to show that each of these components is really mandatory ?

...

Well, okay.

1/ Today, using daily a workstation without pulse/pipewire is a PITA.
2/ Today, having a little control on what several users can simultaneously do or not on a workstation without a login service is a PITA.
3/ What else do you suggest to manage my input devices ?
4/ Considering the loooong time this ugly package takes to compile, do you really think I never tried to avoid it ?
5/ see 3/
6/ see 3/, 5/, and Neddy"s signature.

[stefan11111]

I understand that you must use networkmanager, which needs libudev, and it's gui needs libgudev.
What do you need pipewire for?
What do you need elogind for?
What do you need libinput for?
What do you need qtwebengine for?
What do you need usbutils for?
What do you need libatasmart for?

Seriously ? Do you really want me to show that each of these components is really mandatory ?

...

Well, okay.

I asked in the hopes to maybe trim down that list.

1/ Today, using daily a workstation without pulse/pipewire is a PITA.

Your call. I only use alsa

2/ Today, having a little control on what several users can simultaneously do or not on a workstation without a login service is a PITA.

I thought you use it for xorg only. If you need it, keep it.

3/ What else do you suggest to manage my input devices ?
4/ Considering the loooong time this ugly package takes to compile, do you really think I never tried to avoid it ?
5/ see 3/
6/ see 3/, 5/, and Neddy"s signature.

What do you mean "manage input devices"?
If you mean xorg drivers, use the drivers from neddy's overlay.
What do you need qtwebengine for? You didn't answer that. If you don't want to, that's fine.

[Syl20]

Your call. I only use alsa

After several years of hellish (see my previous posts if you have such time to loose) and hard resistance, I finally decided to install pulseaudio to solve my audio problems. I wish you never have to deal with a dmix bug, or sort of.

What do you mean "manage input devices"?
If you mean xorg drivers, use the drivers from neddy's overlay.

I'm surprised to learn that xf86-input-mouse and xf86-input-keyboard drivers are still maintained upstream. That said, even their maintainers recommend using something else for linux users. Like (now old) xf86-input-evdev, or... xf86-input-libinput.
Personally, I can't remember when I switched to xf86-input-evdev. That was so many years ago. Even my oldest system backups are not so old.

What do you need qtwebengine for? You didn't answer that. If you don't want to, that's fine.

https://www.slicer.org

[mid-kid]

For those opposed to running udev, what is the motivation? Are there specific technical problems with the released udev we use today? Is this a philosophical objection since the systemd project hosts the udev code, and systemd's most active contributors have a history of questionable decisions, thereby tainting all projects in that repository? Is there a concern that an announced upcoming systemd-udevd change will introduce technical regressions relative to the currently released udev?

I hesitate to reply in a heavily derailed thread, but I haven't found a better way to share my thoughts, and this is the only sane message in a topic that doesn't do anything but derail everywhere I read about it, so I wanted to honor it.
I think you've hit the nail right on the head. I use linux distributions and prefer them over upstream packaging mechanisms because they're made by people who have interests similar to mine, those of a software's user. They are interested in things that upstream developers rarely care about, such as fostering a well-integrated and consistent software ecosystem around an operating system, and keeping anti-user functionality out of the system.
In this context, my view of (and purpose for) eudev is very similar. It's a way for distros with similar goals (usage without systemd) to get together and maintain a solution that better caters to them. It's also one step further removed from the systemd upstream, one that has historically not cared about anyone but themselves, and allows adding features that they would never allow. I guess it's very hard to see this as a real justification when eudev is "just a fork of an old copy of systemd", and I understand that it's really tedious to maintain, especially when the rationale isn't very sound, but I will lament it being gone.

As an aside, I have an actual regression if I were to move to systemd-utils' udev, which is that USE=rule-generator doesn't exist. I'm not sure how to replicate its behavior in the new udev (that of updating /etc/udev/rules.d/70-persistent-net.rules when new network devices are detected, providing an automatic "persistent" naming for them despite using the old interface naming), though from asking around I've learned that I'm probably the only person on this planet interested in the functionality, unfortunately.