Bug#982147: mgba: Please provide a libmgba-dev package

[Ryan Tandy]

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