Dependency on eudev

[Riteo]

Hi! I found out that a few packages depend on eudev:

• libgphoto2
• chromium (not really in the depends file, but post-install advises installing it or udev-zero in order to pass some checks)
• tlp
• usbutils

I tried removing the eudev dependency in usbutils and it works fine. Since it's not immediately clear on why those packages depend on it and installing those (pretty popular) packages would require swapping a relatively important system component, would it be possible to document (or at least explain as a comment here) why is eudev needed as a dependency of these packages, maybe even in the proposed per-package README file?

[dilyn-corner]

This would be up to the maintainers to answer:
libgphoto2 -- @Vouivre
tlp -- @depsterr
usbutils -- @trbednarzyk

[rachelambda]

TLP is no longer maintained by me, I recall leaving it up for grabs, either I'm misstaken or no ine has picked it up

[Vouivre]

I will have a look at the README when I will have time. In between, libgtphoto2 creates some udev rules. With
those rules, the user can have access to the camera, otherwise only root can access the camera. It only works if
eudev is installed. Perhaps a more lightweight solution is possible (mdevd for example). I'm interested by any suggestion.

[Riteo]

@Vouivre I've found a way to achieve something similar, although I haven't still tried it for your package. android-tools accesses its android devices directly through the USB and due to this, can't work as is without running its server as root. For this exact reason android-udev exists to provide rules for providing access to normal users by checking for a specific vendor and product id and chmoding the device's USB port device file. Apparently this is easily doable by detecting all usb events using the command syntax (see mdev's documentation and, for a more real example, this mdev-like-a-boss's config line) that, through its enviroment variables updated by mdev, checks for the right vendor and product id and chmods it.

Speaking in real terms:

mdev.conf (not the whole file, just the addition):

# Run /etc/mdev.d/android-mdev (could be anywere) on any usb insertion event.
`SUBSYSTEM=usb;.* root:root 660 ! @/etc/mdev.d/android-mdev`

/etc/mdev.d/android-mdev:

#! /bin/sh
# Just an example, filters a single (null) device.
# The string that gets set on PRODUCT has the following format:
# vendorId/productId/revision
#
# DEVNAME is a path relative to /dev to the device file.
# These enviroment variables get set by mdev from the USB uevents, look at them
# for more information.

if [ "$PRODUCT" = "0000/0000/000" ]
then
	chmod g+rw "/dev/$DEVNAME" 
	chgrp android "/dev/$DEVNAME"
fi

This is just a proof of concept, but this mechanism has a lot of potential. IMO the script should read by itself a separate list of allowed devices, in order to avoid dependencies on specific device managers, but this is up for discussion. Maybe this could even be included in the core busybox package?

[dilyn-corner]

Correct, a large number of udev rules are simply to set proper permissions on device paths -- if these packages only require eudev for this functionality, this can be accomplished (perhaps nontrivially) in many different ways. For instance, the kernel has a builtin way of doing this (UEVENT_HELPER). libudev-zero includes helper.c (though I'm not certain how its functionality has changed since the 1.0 release).

We already suggest taking @Riteo's suggestion -- see how Dylan handles libudev-zero and the mdev.conf here: https://github.com/kisslinux/repo/tree/master/extra/libudev-zero (the mdev.conf suggestion already exists in the busybox package: https://github.com/kisslinux/repo/blob/master/core/busybox/files/mdev.conf#L72-L74). So we have two options in these cases:

1. Pester Dylan with a PR to add these changes to the mdev.conf included with busybox
2. Tell users what to do in something like a post-install file OR do it for them

The first option only helps people who use a 'default' KISS system. Option 2 would solve this problem on a per-package basis, which is probably preferred (the main repo should only really include what's necessary to "get off the ground" with KISS, not "extras" like Android devices when you have to install a package for that on top of what busybox is providing).

As for whether it's done automatically for users (like https://github.com/kiss-community/community/blob/main/community/oksh/post-install) as opposed to manually by users (like https://github.com/kiss-community/community/blob/main/community/openntpd/post-install) is up to the maintainer IMHO.

[Riteo]

@dilyn-corner the issue with auto install or even just manual configuration is that it's too unstructured by itself. What I proposed to include in repo was really just a script/folder and its respective hooks already setup by default for a more modular and less error prone device hook system. Kinda like dylan's boot manager agnostic boot system. I am aware of solutions like uevent or even the kernel's own hotplug system. The idea behind this is that, being uevent arguments consistent, as long ad a device manager can run scripts it should be a agnostic as it can be, even by just running uevent through it.

[dilyn-corner]

Let me rephrase what I was trying to say:

I don't know what your suggestion is accomplishing that isn't already solved, and the original aspect of this issue ("why do these things depend on eudev") is resolved by my suggestion to fill the gap on the already existing solution

Tell users what to do in something like a post-install file OR do it for them

[Riteo]

@dilyn-corner oh, sorry, maybe I didn't explain myself correctly. I'll try rephrasing everything for clarity; if even then the thing sounds dumb, sorry!

The issue is simple: Swapping for eudev could be avoided pretty easily with just a custom script for detecting the right USB device using mdev, mdevd, uevent, hotplug or any other sane device/hotplug manager which can run a script with the (pretty much standard AFAICT) uevent arguments.

That's the premise of this whole thing, and I think you got that correctly.

The other part is the actual suggestion part. Your suggestion is fine, but I criticized the complexity in installing and one of those packages: the instructions are only for mdev and you still have to put an entry manually.

That's why I proposed a more structured approach. It isn't going against your suggestion, it's trying to make it more hassle free.

Since the whole deal depends on simple shell scripts run as root, I thought we could be inspired by another of Dylan's works: KISS's init framework and in particular, its init-agnostic hooks. I was thinking, why not make something simliar to /etc/rc.d/ but for device hooks?

So the idea would be the following: Instead of manually configuring everything, we could have a /etc/uevent.d/ (or a similar path) directory, with an usb folder in there.

Then, to make it hassle free by default we could make /etc/mdev.conf have something like this by default:

`SUBSYSTEM=usb;.* root:root 660 ! @for i in etc/uevent.d/usb/*; do ./$i; done

(I don't know if for loops work with syntax. If not, a simple script that does the same thing or maybe even just passing it as an argument to sh -c should work fine)

Then every package needing custom USB (or potentially even other, if so configured) hooks could put their own in there, without having to mess up with configurations or neeeding user intervention. This could also make it device manager agnostic, since it only relies on the kernel's own uevents (you could even literally run uevent sh -c 'for i in /etc/uevent.d/*/*; do $i; done' and have a working dynamic hotplug system with custom rules).

If that sounds too complicated obviously we can discard this idea, but at least I hope I made it clear.

[dilyn-corner]

I understand all of this, but my claim is that essentially no extra work is basically required to not use eudev in the cases where it is only used for appying rules that simply adjust permissions -- the framework for this already exists in out /etc/mdev.conf, or a myriad of other ways. We don't need to add any extra bits.

If a specific package requires something over and above permission changes on dev nodes for it to work properly, then it should either do that manually or notify the user, a la post-install.

It isn't that your suggestion is too complicated, it's that it's roughly just a shim over an already existing solution space.

[Riteo]

@dilyn-corner oh, are you telling me that we could avoid running a script directly? Like, taking the android example, doing something similar to this?
PRODUCT=0000/0000/000;.* root:android 660 !

[dilyn-corner]

Is it actually the case that for android-tools to work properly the specific USB device has to be root:android?

[Riteo]

@dilyn-corner any name will work fine.

[dilyn-corner]

(Sorry for the delay)
So why do we need more infrastructure over and above what we already do for something like openntpd?

Perhaps it's best to poke Dylan's brain about a more generic sort of device management framework. We should aim to be agnostic in this repository and conform with the upstream KISS standards and practices.

[Riteo]

@dilyn-corner Well the "infrastructure" would've been really just a common place to put scripts, to avoid manual and potentially messy copy-pastes. That was sort of my proposal, a generic device management framework of sort, after all we already have an init one which does even more of the proposed device manager framework. You're right though on the good practice of following upstream's conventions and as such I probably should've gone straight to Dylan in the first place. If you wish I can do it myself as soon as I have time.

[Vouivre]

Sorry for not responding, I need a better understanding in this issue, but at the moment I can't. If something
must be done on my package, you can make the change without problem. I expect I won't be able to have a better
look before a few weeks.

[Vouivre]

I'm back in this thread, sorry for the delay. @Riteo can you confirm me there is nothing to do on the package at the moment until you contact Dylan ?
To be honest, I still don't have an overview of the possibilities to solve the issue. I only have a better
understanding of mdev.

[Riteo]

@Vouivre yes, exactly. Actually I don't think that a deep understanding of eudev will be actually needed, so don't worry. :)

[Vouivre]

@Riteo Thank you!

[dilyn-corner]

Assuming libgphoto2 is trapped forever with eudev, considering this closed.

[Riteo]

Yeah this issue can't really be fixed without some new radical solution made by someone and miraculously accepted by everyone or by Dylan and his public return. I agree on your decision.

[git-bruh]

Continued in kiss-community/repo#89