Bug#974139: libpango1.0-dev: PangoFcFont, PangoFcFontMap no longer subclassable

[Simon McVittie]

On Wed, 11 Nov 2020 at 02:18:52 +0100, Marc Lehmann wrote:
> it's trivial to avoid in debian by bumping the
> soname, so old binaries don't cause bad things to happen to users

Distribution-specific SONAME bumps, without coordination with upstreams,
cause incompatibilities for years to come (see: libcurl) and I would
strongly prefer to avoid them. The upstream developer of a library "owns"
the namespace of SONAME version numbers; if we bump the SONAME version,
then we cannot complain when the upstream later uses the same version
number for a different ABI, leaving us unable to ever re-converge.

It is also the upstream developer who decides which parts of a library are
or aren't considered to be part of the public API/ABI. Yes, reclassifying
public API/ABI as private breaks derived projects that were relying
on it, and it's unfortunate that the Pango maintainers were unaware
that derived projects were relying on this part of the API; and yes, we
*could* make a Debian-specific fork of Pango, and link our GTK/etc. to
a Debian-specific Pango branch instead of the upstream Pango; but that
doesn't seem a sustainable thing to do.

I'm sorry that this has broken your use-case, but I don't think taking
an adversarial tone is going to help you to achieve the result you are
aiming for. People who perceive that they are being attacked will tend to
become increasingly defensive and unwilling to change their position,
which is presumably the opposite of what you want.

    smcv