Roadblock(s) already here. I've experienced one software that won't compile because it uses features introduced since udev-182. I'm sure this will happen more and more with new software projects. I was able fix that problem locally by installing just the udev component from systemd-215 (should work for 216 too). However this makes that machine quite non-standard - not so attractive if you have a bunch of machines to maintain. I understand a "standalone-udev-from-systemd" proposal has been put to Pat - hopefully it has sufficient merit to be included soon.

Maybe that will be true in the future but not at the moment. Based on minimal research suggesting udev could be built/installed separately from systemd, I tried it myself and it worked. In addition, the fact there is a separate proposal to Pat to do exactly the same thing indicates that at least one other person has gone through the same process and succeeded.

i.e. for some time at least, we don't need an alternative to udev; we could have 216 right now.

chris

I know a few experimental builds of eudev have been tried on Slackware. Someone did test a package of eudev-1.7 if memory serves. The post might still be lingering here.

I think it's this post by Didier Spaier. Haven't tested it, though. (I also read that CRUX switched to eudev in 3.1.)

A lot of smaller non-mainstream distributions have picked up eudev which is nice to see. Mostly, from looking into it, lots of these distributions still want a lighter weight system. A few even have been picking up other packages like perp, Runit, and other low level toolkits for not just device management but init and other services. I think there's even a few novelty distributions out there still sporting hotplugd, hald, and devfsd and lack udev completely that also are up-to-date in most software oddly.

Oh, I did not experience this, I've used firefox 31.0 (via ruario's script) and had no problems accessing it. One can also check it out using git(1):
Yes, I already wrote on Alien BOB's blog that VoidLinux switched from systemd to runit. Nice to see indeed. As for distributions still using hald etc. but being up-to-date: I remember a while back that a user posted a link to a blog where someone complained about Mesa depending on libudev for DRM hardware support, so he wrote libudev-light. Seems as if more and more workarounds are needed.

Could you say what software? and what features were missing?

TIA

I remember about libudev-light being written for that purpose. The thing is, regardless of all the changes that have gone on in GNU/Linux, all the old paths, libraries, and functionality is still there. Projects still have the hal fdi resources available, netlink isn't going anywhere, and as it was pointed out the kernel hotplug code is still alive too, and all of these were deprecated years ago, but they're still there because of the fact many low-level embedded systems still run the technology, because it's simpler and still works.

I'm not saying it can be done easily, but there are patches that allow hald to build, hotplugd scripts need updates, and devfsd still builds perfectly. All the classic methods to getting a system up and running just require some patches really. FreeBSD still uses hald with devd mostly because they don't use ConsoleKit and devd doesn't reproduce some of the udev functions required, but it works.

I think really all this rush to kdbus stems from nothing but FUD talk. If stuff from kernel 2.4.xx and even 2.2.xx still exists for whatever reason out there, then really there are no worries. And until kdbus is put into the kernel this FUD talk amounts to nothing but someone trying to blow smoke up another's rectal area, and possibly even after it is put in.

Some stuff still exists because nobody saw the need to remove it.

The word "bitrot" comes to mind.

The software is colord version 1.2.1 (some earlier versions also failed). After configuring with --disable-bash-completion and --disable-systemd-login, make stops when linker can't find libudev.so.1. However there are also prior warnings about implicit declarations of some functions (udev_hwdb_new, udev_hwdb_get_properties_list_entry, udev_hwdb_unref) i.e. they're not declared in libudev.h (which has no hwdb related declarations at all). All was fixed with udev-215. I haven't tried eudev but it would probably work - looking through its github pages, I see the missing declarations are there.

chris

udev-215 should be equal to eudev-1.9 in feature support. I've got colord-1.2.1 compiled again eudev-1.7. Didier had a build as posted above. Ask him. Eudev was his baby. He should know.

Thanks for the detailed info. It highlights a new issue I was not aware of: The systemd/udev team have added all the hwdb stuff in udev!! It is a new subsystem ('udevadm hwdb' command, /lib/udev/hwdb.d rules, udev_hwdb API in libudev-hwdb-def.h) for enumerating and getting textual description of hardware devices (PCI and USB).

This is bad news, because others upstream projects, such as colord for example, will start using this stuff. This will in turn make a udev fork even more difficult to maintain :-(

Regarding the specific colord issue, I think you could build it with our current udev-182 with .configure --disable-udev --disable-systemd-login. I tried to build it on my home PC but unfortunately I am running Slack 14.0 here, and colord's configure requires Glib>=2.36...

1 members found this post helpful.

libudev.so.1 should be a symlink back to the main library libudev.so... unless something changed recently.

Try running a search for libudev and see what comes up. If the symlink is missing you may have to create it.

How to build colord isn't the issue - I only mentioned it in response to a direct question.

The actual points of my original post were:
1. sticking with udev-182 does constitute a roadblock
2. doing without systemd does _not_ necessarily require an alternative to udev, just an up to date version of udev

The fact that eudev also does the job is great. Whether to use eudev or an up to date udev is a different matter - hopefully one or the other will go into -current soon so that the technical implications can be tested more widely and more thoroughly.

chris

Yes, I understand that eudev has more features and is closer to systemd-udev than our current udev-182.

Maybe I don't get it right, but for the moment I do not see eudev as a real udev fork (where both projects start having different and divergent lifes), but more as a continuous effort to unbundle the udev part from systemd. This effort is cool, but I am afraid that the more the udev source becomes tighly tied to other systemd parts, the more difficult it will be to unbundle it. So I am not optimistic that the eudev project is sustainable. Though I would love to be proven wrong.

If you run such a search yourself on a stock Slackware system, you'll find that libudev.so.1 does not exist - just libudev.so as a symlink to libudev.so.0.XX.XX (depending on Slackware/udev version). Therefore, creating a libudev.so.1 symlink was one of the first things I tried but of course it was doomed to fail since, as I mentioned earlier, the library doesn't contain the necessary functions.

chris