Le jeudi 2 août 2012 10:31:04 Pascal Terjan a écrit : > On Thu, Aug 2, 2012 at 10:17 AM, Colin Guthrie <[email protected]> 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/m > > aster/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/a > > c2270b1f9c445fd39e48051b99d35d9b9693a34 > > > > 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.
I think that we better should see with attica devs to ask a major increase.
