[Xcb] [PROPOSAL] how to solve ABI/API issues when fixing protocol definition bugs

[Christian Linhart]

Hi Uli and all,

Bumping the soname is a simple solution (which is good).
(Does it have any undesirable side-effects?)

For the xinput extension we may be able get away with this because
it does not seem to be used yet for any relevant application.
At least on my Debian and Ubuntu systems it does not
appear in "/var/lib/dpkb/available".
(I guess this is a rather strong hint.)
If you know about any application that already uses xcb-xinput
please post this here.

XKeyboard is another story. It is enabled by default but it is bugridden.
But we don't have any fixes for XKeyboard committed yet.
Just an RFC-patch posted from me. So, that problem is postponed. :-)

With extensions other than XInput we'll have to
maintain ABI and API compatibility for the upcoming release,
and I think that that's doable. (but needs QA-work and possible adaptions)

So, for the upcoming release, that's fine.

***

In general, bugfixes that change the ABI/API are made
because the old version is broken. You are right on that.
But, it is still possible that broken code sometimes works,
so it may be in use already. (That's primarily an ABI issue, then.)

If the API needs to be changed to fix a bug, then changes in the
applications are needed, too, to fix that bug.
Therefore the developers/maintainers of applications should
be thankful that they are pointed to a possible
bug, and given a chance to fix it. :-)

***

During comparing the Xinput-API, I have found one issue which
we probably need to fix because it probably breaks ABI
for other extensions, too:
If adding alignment pads to the case or bitcase branches of a switch,
then pointers to these alignment pads appear in the struct used
to store the deserialized data.
(e.g. "xcb_input_change_device_property_items_t" )

This changes ABI unnecessarily because these pads are not meant
to be accessed and therefore shouldn't appear in these structs.

Cheers,

Chris


On 2016-01-10 18:49, Uli Schlachter wrote:
> Hi,
>
> Am 10.01.2016 um 15:59 schrieb Christian Linhart:
> [...]
>> So, we have the following situation:
>> * The protocol definitions in the last official version are pretty buggy.
>>     (at least in some extensions such as Xinput an XKB)
> [...]
>
> How broken exactly? If we only break code that never worked in the first place
> and which required enabling things which were disabled by default, then what
> reasons speak against a soname bump?
>
> It's not a long term solution, but even then I'd think that the only reasons for
> ABI/API breaks is "the old version was broken".
>
> Uli