shared library version compares older than a "real" libudev.so.0

[smcv]

The last official release of libudev.so.0 as its own library with non-trivial code was 182, which appears to have been versioned as libudev.so.0.13.1:

LIBUDEV_CURRENT=13
LIBUDEV_REVISION=1
LIBUDEV_AGE=13

(this is in the confusing Autotools setup where the major version is CURRENT - AGE, the minor version is CURRENT and the micro version is REVISION).

This libudev.so.0 shim is versioned as libudev.so.0.0.9999. This means it compares (in strverscmp() order) as being strictly older than "real" libudev.so.0 releases.

The result is that if you have this libudev.so.0.0.9999 and a stale copy of udev's libudev.so.0.13.1 in the same directory, ldconfig will prefer to use udev's libudev.so.0.13.1 to implement the libudev.so.0 SONAME, but presumably this decade everyone should prefer to use libudev0-shim's libudev.so.0.0.9999.

Similarly, when the Steam Runtime does its setup, it uses libraries' filenames (in setup.sh) to identify which ones are older or newer in the Steam Runtime, and which ones are older or newer on the host system. This is because it wants to use its own copy if that's newer (for example it has SDL 2.28.x, but might be running on an old Ubuntu LTS system with an older SDL), or use the host system's copy if it's newer or equal (for example the host system's libglib-2.0.so.0 will nearly always be newer than the Steam Runtime's). Unfortunately, by that logic, the Steam Runtime's very old libudev.so.0.13.0 (from udev v175, via Ubuntu 12.04) is considered to be newer than libudev0-shim's libudev.so.0.0.9999.

If libudev0-shim bumps its version number to .so.0.13.9999 then it will compare newer than any "real" libudev.so.0 release, which is presumably preferable in all cases.

I'm going to look into whether we can work around this in the Steam Runtime, but it would be nice to fix this upstream in libudev0-shim.