While looking into fixing #1118879, I noticed that gir1.2-mypaint-1.5
doesn't contain MyPaint-1.5.typelib as its name would suggest. Instead,
it contains MyPaint-1.6.typelib. This means that a calling sequence like
this Python, or its equivalents in other languages, in a package that
Depends on gir1.2-mypaint-1.5:

    import gi
    gi.require_version('MyPaint', '1.5')
    from gi.repository import MyPaint

would have worked in early 2020 but no longer does.

A mitigation is that nothing seems to depend on gir1.2-mypaint-1.5, so
perhaps no interpreted programs are impacted by this - that's why I'm
not reporting it as RC.

I see that there's a patch,
d/p/0003-Makefile.am-Hardcode-release-LDFLAGS-for-now.patch, which rolls
back the SONAME of the shared library from libmypaint-1.6.so.1 to
libmypaint-1.5.so.1 to avoid needing a transition. However, this patch
doesn't cover the --nsversion argument passed to g-ir-scanner, which is
also part of the API/ABI.

One way to resolve this would be to roll back the --nsversion to 1.5, In
general, everything that is based on LIBMYPAINT_API_PLATFORM_VERSION
should probably move in lockstep.

Or, the package containing the typelib could be renamed to
gir1.2-mypaint-1.6 to reflect its contents.

For #1118879 I'm going to introduce a workaround (which will become
harmless after this issue is fixed) rather than fixing this properly,
so that the package's maintainers can choose which of the routes to take
to fix this issue.

In general I think it's a bad idea for Debian to have an API/ABI that is
incompatible with what is shipped upstream, so API/ABI versioning should
usually be fixed upstream or not at all.

    smcv