Re: [PATCH] libxencall: Bump SONAME following new functionality

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.06.2021 13:36, Andrew Cooper wrote:
> On 25/06/2021 11:59, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH] libxencall: Bump SONAME following new 
>> functionality"):
>>> On 25.06.2021 11:17, Andrew Cooper wrote:
>>>> On 25/06/2021 07:31, Jan Beulich wrote:
>>>>> On 24.06.2021 19:55, Andrew Cooper wrote:
>>>>>> Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() 
>>>>>> returning long")
>>>>> Is this strictly necessary, i.e. is a Fixes: tag here warranted?
>>>> Yes - very much so.
>>>>
>>>> andrewcoop@andrewcoop:/local/xen.git/xen$ readelf -Wa
>>>> ../tools/libs/call/libxencall.so.1.2 | grep 1\\.3
>>>>     33: 0000000000001496    59 FUNC    GLOBAL DEFAULT   13
>>>> xencall2L@@VERS_1.3
>>>>     39: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS VERS_1.3
>>>>     76: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS VERS_1.3
>>>>   020:   4 (VERS_1.2)      5 (VERS_1.3)      2 (VERS_1.0)      3
>>>> (VERS_1.1)  
>>>>   024:   3 (VERS_1.1)      2 (VERS_1.0)      4 (VERS_1.2)      5
>>>> (VERS_1.3)  
>>>>   0x0080: Rev: 1  Flags: none  Index: 5  Cnt: 2  Name: VERS_1.3
>>>>
>>>> Without this, you create a library called .so.1.2 with 1.3's ABI in.
>>> I'm aware of the change to file contents as well as the disagreement
>>> of file name / SONAME vs enumerated versions. So telling me this is
>>> not really an answer to my question. It may be by convention that
>>> the two should match up, but I don't see any functional issue (yet)
>>> if they don't. Plus of course you leave open altogether the
>>> backporting aspect of my question.
>> The patch, including the Fixes tag,
>>
>> Reviewed-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>
> 
> Thanks.
> 
>> Changing minor version in the filename as well as the .so is not an
>> impediment to backporting.  The actual soname remains the same so
>> there is no compatibility problem and the change is still suitable for
>> including in eg distro stsable releases.
> 
> Correct, although backporting in general however is problematic.
> 
> Until Xen 4.16 is released (or, we explicitly decide to make an explicit
> library release early), the 1.3 ABI isn't set in stone.
> 
> Backports to older stable-* branches must sit on a boundary already set
> in stone in staging, or we'll end up with different versions of Xen
> having different ideas of what VERS_1.3 mean.

Which effectively means we'd have to open 1.4 despite being in the
same release cycle if this change got backported. Or did I not
understand correctly what you were trying to say?

Jan