Version number should be greater than the last udev that shipped libudev.so.0

[smcv]

The last official release of libudev.so.0 as its own library with non-trivial code was part of udev v182.

To ensure that libudev.so.0 can be upgraded smoothly from the version shipped with old udev to this version, it would be nice to have a version number that is strictly greater than 182. In distributions that normally include libudev as part of a larger package (like Arch) it probably doesn't matter either way, but in distributions that have a policy of separating out shared libraries (like Debian and openSUSE) it can become important.

The Debian packaging for this project achieved this effect by repackaging v1 as though it had been versioned v200. If there's a new upstream release with #3 and/or #5 merged, it would be useful if the new upstream release was versioned v201 or higher.

[smcv]

@evelikov, if you're looking at taking over this project and making a new release with the two pending MRs merged, would you mind versioning it v201 or higher? That would make it easier for me to get the version in Debian updated.

[evelikov]

@smcv I don't particularly follow - there is a git tag called "v1" which is an arbitrary number. If Debian or any other distro for that matter chose to version their package v200 that's fine.

Need to check the v201 ABI and if the shim is compatible then we can do. Otherwise, I'd leave it as v2.

Speaking of which - would a libudev0-shim.pc be beneficial for Debian and/or the Steam Runtime?

[smcv]

there is a git tag called "v1" which is an arbitrary number. If Debian or any other distro for that matter chose to version their package v200 that's fine.

To be honest the Debian maintainer probably shouldn't have changed what is meant to be the upstream version field to v200 without talking to upstream, but I don't have control over that and they already did it, so it's too late to revisit that decision. Presumably they were assuming that there would never be a second release.

Need to check the v201 ABI and if the shim is compatible then we can do. Otherwise, I'd leave it as v2.

The reason that the Debian maintainer used v200, and I'm suggesting v201 here, is that there has never been and presumably never will be a libudev.so.0 release newer than 182, other than as part of a shim like this one: udev <= 182 were an independent project, then it joined systemd, and all systemd versions v183+ shipped libudev.so.1 instead.

In the Debian packaging (and presumably any other distro that separates shared libraries in a similar way), libudev0 versions 1 to 182 came from udev, libudev1 versions 183+ come from systemd, and meanwhile a parallel series of libudev0 versions 200+ come from libudev0-shim.

I was thinking of this libudev0-shim as being basically a continuation of the old libudev.so.0, so it's "the same shape" as what happened when gudev separated from systemd: gudev 218 was part of systemd 218, but gudev 219 and up were their own project and took responsibility for their own versioning.

Speaking of which - would a libudev0-shim.pc be beneficial for Debian and/or the Steam Runtime?

I don't think so? .pc is for linking, and nobody should be linking new code to this library: it's only here for the benefit of old binaries that haven't yet been re-linked (and in most cases never will be).

It probably also wouldn't be useful to provide a libudev0-shim.pc unless it came with a libudev.so symlink so that you could link with -ludev, but that would conflict with libudev-dev (the one from systemd, pointing to libudev.so.1).

If you recompile software against a recent SDK for even the oldest branch of the Steam Runtime (scout, based on Ubuntu 12.04) and it links to -ludev, what you get is a dependency on libudev.so.1.