[Mageia-dev] Library policy query: What do we do when SONAME includes both major and minor? (Re: [changelog] [RPM] cauldron core/release kdelibs4-4.9.0-2.mga3)

Thu Aug 2 11:35:55 CEST 2012

Le jeudi 2 août 2012 10:31:04 Pascal Terjan a écrit :
+> On Thu, Aug 2, 2012 at 10:17 AM, Colin Guthrie <mageia at 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 at 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 at 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.
+