8th november 2013 beta REGRESSION
I would like to point out that introducing libudev.so.0 as a dependency NOW is a really bad move considered that the library is already obsoleted by libudev.so.1; and the client was working fine without it.
Fedora 18, due to end of life in January 2014, is the last supported Fedora release with libudev.so.0. RHEL 7 will not have that as well.
The addition of the libudev usage is deliberate. The Steam runtime is our official solution for managing binary dependencies so systems that aren't using it are exposed to breakage, that is unfortunate but expected.
I'm closing this out as we'll keep #2972 for future consideration of changing libudev versions in the Steam runtime.
One question: can you track down where the libudev.so.1 usage is coming from? I do not see any such usage in steamclient.so itself, just the expected libudev.so.0. An ldd on my Ubuntu system doesn't have any reference to libudev.so.1, so is there indirect reference, such as a Fedora binary that is picking it up? I don't see a libgudev dependency on 32-bit either, but do see it for 64-bit (pulled in by libnm-glib).
Another question: is it necessary for you to run without the runtime?
Actually the libudev.so.1 requirement comes from libusb:
/lib/libusb-1.0.so.0:
libudev.so.1 (LIBUDEV_183) => /lib/libudev.so.1
[...]
But I can't track down the libgudev dependency...
The Steam Runtime was disabled to solve sound issues and graphical glitches when running the client under Fedora. Actually it was also suggested by one game developer which has some games on Steam during the Fedora review of the package. When I first created the package (around version 1.0.0.22, though) sound issues were common, but haven't tested it recently since it was working fine with the Steam runtime disabled.
Graphical glitches are still there; when I switch to big picture mode or when I launch games from the interface I have parts of the previous screen (i.e. part of the client) still visibile as blocky rectangles over the current screen and they never go away unless you start something else (another game, go back from a game to big picture; etc.). This does not happen without the runtime. I'm using Nvidia drivers, but I experienced the behaviour also on Intel drivers.
On top of this, the client can get really "fat".
$ du -hs --exclude=SteamApps
1.3G
$ du -hs --exclude=SteamApps --exclude=steam-runtime
992M
$ du -hs --exclude=SteamApps --exclude=steam-runtime*
805M
So removing 400mb of duplicated libraries can still be a good point.
One question please; if the Steam client is going to link to libudev.so.0 by default I need to make the Steam package enable the runtime again, or all Fedora RPMFusion users will be affected. The update will usually take at least one week before getting released through the usual update procedure.
Will I be able to make it before you release the beta as official?
Thanks.
We don't tend to have firm schedules on releases so I can't guarantee anything, but my personal guess is that the beta will be promoted some time next week. That might be a little early for you but not a ton.
Just for reference:
Having everything on Fedora glitch that badly is sucky, so we've been talking about options but at the moment there aren't easy solutions. We can't quickly diagnose the issue when running with the runtime and we can't easily remove the udev usage, but we'll keep looking for some kind of middle ground.
Thanks, appreciated. Love Steam and already own 70 games, would like to have it a little less cumbersome and complicated.
Talking about libraries; do you think it would be possible to have the Flash plugin already in the client download? We are forced to have half a gig of Ubuntu libraries but need to install the Flash plugin by hand.
Redistributing Adobe's code is problematic, plus there's the whole issue around their support, or lack or, for Linux Flash. We don't have plans to try and distribute the plugin right now.
Thanks for your quick answers!
Things are not looking good for changing Steam. Do you know if other Fedora users have the same graphics and sound issues with the Steam runtime?
As the Steam runtime has libudev.so.0 and has for a while that's the version that Steam would use given that the Steam runtime is our target. Changing the Steam runtime is not really possible since the point of it is that things don't go away unless we're switching to a new epoch, and we've barely started on the first one. Packaging libudev.so.1 in the runtime is theoretically possible but has a number of problems itself, thus my comment about us not having any easy solutions.
This is a bit of a riddle, libudev.so.1 is not added to ubuntu's packages until 13.04, and libudev.so.0 will not be missing from an ubuntu release until 14.04 comes out. Both library varients work fine with the client, is it possible to just link against libudev.so and tell fedora and gentoo users that any oddities that crop up is their problem.
EDIT: nevermind, I missed the memo that ubuntu does not package the simplified library name
That's a possibility although an outside one. As Steam is set up to build against the runtime, with attendant specific versions, we'd have to do some special-casing for just libudev to link it differently. Doing that once by hand wouldn't be so bad, but we'd need to set it up to have it work automatically, survive updates to the runtime, etc.
@gdrewb-valve I have heard a few reports from persons who have issues, I personally have the same issue with various iterations of Nvidia drivers, Intel drivers and Nouveau drivers on a mix of Fedora 18/19/20 systems. I could organize a poll but I doubt users will partecipate. My last i686 system is on Fedora 18; all the others are x86_64.
@Tele42 my point in the first comment was simply to avoid adding new libraries to which the client links to that are already obsoleted. For example udev has been merged into systemd in April 2012, why start linking the already obsolete library in November 2013? That's almost 2 years old. At least link it to what's "current".
I'm not asking to provide clients or specific linkage for every distribution, just linking to something "recent" would suffice and would make it easier for Valve to have adoption of Steam on other Linux platforms where packagers solve issues you don't really have to worry about (this is my first ticket in one year, the client was working perfectly until November's beta).
As expected I'm getting the first reports of Fedora missing sound if the STEAM_RUNTIME is enabled:
So, with the introduction of libudev.so.0 we can't use the native libraries in Fedora, if we use the Ubuntu Steam Runtime we have to play games without sound. How to fix this mess?
There's no easy way to separate Steam from the Steam runtime since the whole point of it is to be Steam's binary environment. libudev.so.0 has been a pat of the runtime for a while and so can't easily be pulled since that breaks the stability of the runtime, which is what it's for. Putting extra things in the runtime, like libudev.so.1, to allow linking against that just to help people not using the runtime is not a priority. Fixing the problems that occur when the runtime is enabled would be the right thing but that's not going to happen any time soon (unless people maintaining the components look into the problems).
That leaves hacks and workarounds with the runtime disabled. Setting up a redirect of of libudev.so.0 to libudev.so.1 for Steam might be the least nasty?
I'm guessing least nasty workaround is probably to drop libudev.so.0 into a directory that is not resolved by LD_LIBRARY_PATH or ld.so.cache and patch /usr/bin/steam to LD_PRELOAD libudev.so.0 before it goes looking for it.
Nothing extracted yet.
Hello,
I'm the mantainer of the Steam Fedora package in RPMFusion.
The newest beta Steam update breaks compatibility with most systems which don't use the Steam Runtime by reintroducing linking to "libudev.so.0" in the 32 bit client.
Before 8th November 2013 update:
After the 8th November 2013 update:
Opting out of the Steam beta program solves the issue, as the library is not required anymore.