On Sun, Feb 07, 2021 at 10:05:38PM +0100, Celelibi wrote:
The program I'm writing would be an IRC bot a-la twitch-plays-pokemon. I don't think it would be a good candidate for inclusion in Debian as I intend it to be a quick-and-dirty program for my specific needs.
OK. Sounds fun. :)
I have no idea of an ABI compatibility policy. I'm not sure there's one right now.
OK.
However, the CMakeLists.txt already contains everything needed to install headers. So I guess there's an intent toward this usage even if the support (especially regarding ABI stability) isn't well thought out.
Sure. I didn't mean to suggest that the library isn't meant to be used. In fact, It looks like upstream's own .deb packages also include mgba-dev as well as libmgba. However, for publishing it in Debian, it needs to meet the requirements set by Debian policy for shared libraries. (And I'm not even saying that it doesn't, only that I don't know whether it does or not.)
All I can say for sure right now is that the ABI will likely break with version 0.9 because of a new field in the struct Table.
That's fine, as long as the SONAME also changes.
What exactly would be needed from the author of libmgba to make it suitable as a public library? Would it be enough if they set a rule saying that the minor version would be bumped at least on every ABI break?
Specifically, we would want a commitment that there will not be any incompatible ABI change without a corresponding SONAME change. If the SONAME is tied to the minor version, then yes, what you said achieves that. The SONAME change is our trigger to recompile applications; if it doesn't change, we (want to) assume they don't need to be rebuilt.
This may well be how it works already. I just haven't found a written statement about it.
thanks, Ryan
