librpm_sequoia.so should be a link to librpm_sequoia.so.0 not vice versa

[nwalfield]

cargo generates librpm_sequoia.so and the build script creates a symlink from librpm_sequoia.so.0 to librpm_sequoia.so. It should actually be the other way around, but cargo doesn't appear to have a mechanism to do this.

The symlink is needed when, e.g., building rpm against the build artifacts instead of an installed version of the library. Due to the soname, the tests will look for librpm_sequoia.so.0 and won't consider librpm_sequoia.so.

In practice, this mix up isn't a big deal, but packagers need to be careful. @decathorpe noticed this and already took care of it for Fedora.

[decathorpe]

As far as I know, this happens because the default output file name for shared libraries is just the "unversioned" .so file, while in the RPM package, we want the "unversioned" .so to just be a symlink to the versioned file. Other tools for building C-style shared libraries from Rust code handle this at a different point of the build process - for example, cargo-c (which is what we use for other libraries like this) handles this during its "install" (cargo cinstall) step (which the current "manual" approach doesn't even have, hence no possibility to shuffle files around during cargo build).