IBM’s systemd attempt to pull the plug on distros using eudev

libgudev is a low level library that bridges connections between udev and graphic stuff (Gobject) and hasn’t been a problem in the past building it with libeudev instead of its own libudev from systemd.

Edition 238 comes out and specifies in code the udev version limit to 251 or higher, with a specific function checking this in the code provided by a similar function in udevd.  Gnome team is the one publishing ibgudev, so you can’t expect to talk sense into them.  The eudev project recently, carried over from the abandoned Gentoo project, is built on 243 edition.

As described by someone on the open issue of eudev the problem is:

nekopsykose commented Jul 6, 2023

packaging-wise, it’s trivial to just patch such a check (in the meson.build dependency for libudev, inside libgudev’s build; i’ve had to do that multiple times when things declare some high version but don’t actually need it at all).

however, it’s not actually that trivial in this case, because the actual function they bumped for is missing:

../gudev/gudevdevice.c:146:12: error: implicit declaration of function 'udev_device_get_current_tags_list_entry'; did you mean 'udev_device_get_tags_list_entr'? [-Werror=implicit-function-declaration]   146 |   for (l = udev_device_get_current_tags_list_entry (device->priv->udevice); l != NULL; l = udev_list_entry_get_next (l))       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

this was added in systemd/systemd@3b684be, so 247 was the first version with it. there’s no further requirements in this case..

i don’t know how easy it would be to implement this one function.

 

Being a low level library a ton of graphical based software are directly or indirectly linked to it and this may cause several problems to distros being partially dependent for software on a systemd distro, such as Arch or others (later).   If eudev team take too long to address this issue and bump their version up to 251 and above, connectivity will be lost, software will begin breaking based on wrong edition of libgudev, and things generally will begin to fall apart.

Distros that have switched from eudev and build udev/libudev straight out of the systemd repository will face no issue.  So “why is it that this team (gnome, systemd, …pulse/pipew…) want to force people to switch to systemd’s udevd instead of an alternative?  Or is the whole change another attempt to force everyone to abide by their rules and defeat any available choice?

This is why we keep saying that solutions and methods such as what artix uses are only on a legality systemd-free, by altering pid1 from systemd to something else, otherwise udevd elogind and many of their libraries are all there and essential to their system.  Does something like OpenRC pose as an improvement to systemd?

The core question here, again and again, is not what this corporation does to manhandle and control FOSS, is that people don’t see the immoral and unethical ways they employee to control everything and everyone.  Totally against the spirit of gnu, foss, FSF, unix, whatever you want to call it.  They are driving everything to a uniformity of a single system.  Linus is whistling apathetically like if it was none of his business.

So let us see whether the eudev team is up to the task in saving linux for us.  Systemd is up to 253, eudev is back on 243, ten major editions behind.