Extra dependency on libudev.so.0

[Tele42]

The current (as of November 6th) beta steam client's steamclient.so has re-added a dependency on libudev.so.0 in addition to libudev.so.1. This library was dropped from upstream as of udev 205.

The beta client works fine with cross-linking libudev.so.1 to libudev.so.0.

[gdrewb-valve]

The usage of libudev is intentional. As for the specific version, libudev.so.0 is in the Steam runtime and should be coming from there.

[Tele42]

The point of this issue report is to try to reduce hassle down the road, looks like libudev.so.0 is being linked directly to steamclient.so and there should not be anything of provided that is not in libudev.so.1. If and when the steam runtime is remade to something newer, libudev.so.0 will not be available.

If the above statement is not true, then it would be a good idea to document the details for the future.

[scaronni]

Just saw this ticket, I opened a bug for the same reason. Libraries should not link to both libudev.so.0 and libudev.so.1; considering that the first is obsolete in almost every distribution that uses systemd.

https://github.com/ValveSoftware/steam-for-linux/issues/2976

[Tele42]

Note for valve: This issue potentially will not affect ubuntu users until 14.04.

[Tele42]

One way to resolve this issue would be to split the build script in 4-5 months and introduce an ubuntu14_32 binary set, hopefully using common configure/linking elements between ubuntu12_32 and ubuntu14_32 so that changes do not get missed and do not need to be duplicated manually between the two sets.

I assume that valve is aiming for 5 years of support with each LTS desktop, so this will make it easier to cut free ubuntu 12.04 when it's past expiration. (And if it's more trouble than it's worth to maintain.)

[Tele42]

(From a non-programmer's perspective) How hard would it be to make a libudev.so.0 shim that dlopen'd system libudev.so.1, if that is not found, then system libudev.so.0, and if that fails, then steam-runtime's libudev-fallback.so.0. Something similar to line 101 to 134 of http://cgit.freedesktop.org/mesa/mesa/tree/src/loader/loader.c . We did have that rub against mesa from mismatching system and steam-runtime versions being loaded at the same time and clobbering each other.

[gdrewb-valve]

The reason for the numbering is to indicate incompatible versions, thus a shim that simply substitutes one for the other is risky. If libudev.so.1 was guaranteed to be completely compatible with libudev.so.0 the name didn't need to change. If it's not guaranteed to be compatible the name changes and substituting one for the other is not safe. That doesn't mean that particular cases won't work, but in general they aren't interchangeable.

[cjwijtmans]

Why is this marked as not a bug? It is obviously a bug.

[sylware]

libudev.so.1 is now a part of the awful kludge which is systemd... I have not checked how pertinent are the new features of libudev.so.1. I don't think systemd is really a sain component, and "honest". My guess is the guys behind systemd will push hard the major versions of libudev in order to force systemd adoption by the community. I don't use systemd and will never use it (on my custom gnu/linux distro). Maybe the right way to do it is to get directly a copy of the kernel event and parse sysfs. It means to include a fork of udev/libudev.so.0 into steam itself. A must check is to be sure that all kernel event netlink sockets get a copy of the kernel event (and not only one socket, in case you have several "udev" components).