Overview
Why do you think the ABI version is incorrect?
Well, the ABI version is used as X.Y.0 - I am not saying it is incorrect but as far as I understood you, TW requires lib2geom.so.1.2.2?
usually the library ABI version is defined by the progrtam and might not be the exact same as the package version.
I did this in the previous declined request. The ABI is 1.2.0 and so lib2geom.so.1.2.0 was build. The reason for rejection was Library package name is wrong, SONAME is lib2geom.so.1.2.0. Therefore I thought I should change it - could you please guide me which behavior/naming you would like? Thanks!
SONAME and package name have to match. You changed the wrong one. See openSUSE SLPP.
Sorry, I am not really into all the details of packing. If you say changing 2GEOM_ABI_VERSION is incorrect (only seems to change the SONAME), do I understand you correct that I should change the package name? Could you please clarify?
If 1.2.0 is built, then change sonum to 1_2_0 then you will get libxxx1_2_0-1.2.2 which is API 1.2.0 with version 1.2.2.
Now I am getting lost. The readme says 2Geom does not follow Semantic Versioning. Instead, version numbers match major Inkscape release versions. and the release notes say 2Geom v1.2.2 is a point release providing minor bugfixes. Its ABI is compatible with v1.2. Let me also note that e.g. arch is just fine with lib2geom.so.1.2.0, see here.
To my knowledge lib2geom is only required by inkscape which is currently not building due to this missing dependency. I would understand if you prefer the original request with lib2geom.so.1.2.0 or the current lib2geom.so.1.2.2 - I am not sure why it should get more complicated. Could you please provide a link which the exact rules for naming? Also feel free to change this request as you like to make inkscape build again.
The rule is easy. The name of the package must reflect the soname. This is necessary, so that you can install multiple incompatible versions of the library in parallel and also update compatible versions.
If the version 1.2.2 is API compatible to 1.2.0 is logical, that the soname still is 1_2_0.
Most libraries don't use the version, but simply a single number API version. That's less confusing.
So essentially when you build a library and the soname does not match the package name simply adapt the entry to what it is and be done.
As long as the soname stays 1_2_0 future updates of the package can be installed in systems without changes to the using applications.
I assume you misunderstood the original request. They didn't ask you that the package name should match the version. They asked you that the library package matches the soname contained in it (i.e. is set to 1_2_0).
Thanks a lot for explanation! I hope I got it in the updated version...
@StefanBruens, @WernerFink, @adrianSuSE, @bruclik, @dstoecker, @jsmeix, @jubalh, @kfreitag, @mseben, @msmeissn, @t-paul, @toganm: review reminder
