[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)

[Colin Guthrie]

'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/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?

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/