On Thu, Aug 2, 2012 at 10:17 AM, Colin Guthrie <mag...@colin.guthr.ie> wrote: > 'Twas brillig, and Balcaen John at 02/08/12 10:01 did gyre and gimble: >> Le jeudi 2 août 2012 09:28:28 Colin Guthrie a écrit : >>> 'Twas brillig, and Christiaan Welvaart at 01/08/12 23:09 did gyre and >>> >>> gimble: >>>> On Wed, 1 Aug 2012, Colin Guthrie wrote: >>>>> I have to agree here that something is "funny" in the libattica package >>>>> which ultimately helped to contribute to this issue. >>>>> >>>>> e.g. on my system before update (tho' with similar results after): >>>>> >>>>> [colin@jimmy ~]$ rpm -q --provides lib64attica0 >>>>> libattica.so.0.3()(64bit) >>>>> lib64attica0 = 0.3.0-1.mga2 >>>>> lib64attica0(x86-64) = 0.3.0-1.mga2 >>>>> [colin@jimmy ~]$ rpm -ql lib64attica0 >>>>> /usr/lib64/libattica.so.0.3 >>>>> /usr/lib64/libattica.so.0.3.0 >>>>> >>>>> So I can see how this mistake was made and TBH I could have made the >>>>> same mistake myself (with the caveat that I likely would not have bumped >>>>> the version of someone else's package with out confirming first and that >>>>> it should have been obvious from testing and installing the build) >>>>> >>>>> But either way this seems like an issue to fix properly (possibly with >>>>> an upstream fix or some modification to the library policy when the >>>>> minor version is "presented" like this). >>>> >>>> Good catch! Of course it's never the library policy that's wrong. The >>>> library major version is apparently 0.4 so the correct package name is >>>> >>>> lib64attica0.3 for the previous one >>>> lib64attica0.4 for the current one >>>> >>>> ... in the specfile: %define attica_major 0.4 >>>> >>>> Can the maintainer of this package please fix this? >>>> >>>> To find the version to use, look up the 'soname' of the library. I use: >>>> readelf -a /usr/lib64/libattica.so.0.4|grep SONAME >>>> >>>> => >>>> ... Library soname: [libattica.so.0.4] >>>> >>>> What follows ".so." is the major version of the library. >>> >>> Is that really the correct definition of what a "major" version is? >>> >>> I always thought the major was just the first number. >>> >>> The library policy certainly doesn't mention "double digit majors" or >>> similar. >>> >>> Is this something upstream is doing deliberately or is it just an oversight? >> https://projects.kde.org/projects/kdesupport/attica/repository/revisions/master/entry/CMakeLists.txt > > Actually it's this file/line: > > https://projects.kde.org/projects/kdesupport/attica/repository/revisions/master/entry/lib/CMakeLists.txt#L120 > > So it's seems like this was done deliberately due to a ABI breakage a > while ago: > > https://projects.kde.org/projects/kdesupport/attica/repository/revisions/ac2270b1f9c445fd39e48051b99d35d9b9693a34 > > Now, this is an interesting point (regarding our lib policy) bumping the > major for an API change and the minor for an ABI change seems kinda > sensible to me. So how should we deal with that in our policy? Just use > 0.4 as the "major" value here as Christiaan suggested?
A minor change is supposed to only add interfaces and be backwards compatible, that's why it is not in the soname. If there has been an ABI breakage, the major should be incremented.
