On 25.06.2021 12: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 <i...@xenproject.org>
>
> 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.
>
> Not changing the filename is quite strange. I havne't thought through
> all of the implications but I'm sure it will confuse people, and it
> seems like to confuse at least some computer programs that handle this
> kind of thing.
I guess I'm still having trouble seeing the actual issue from not
bumping the minor version of the library. This is still largely
connected to me not seeing how a clean backport here would look
like, in particular if we were to assume for a moment that the
oldest tree to backport to did not already be at version 1.2.
Jan
