> > I prepared a new version of libvhdi, release 20201018. > > I have reviewed your changes and they all look fine except for the > symbols file update; > In that commit we can see that there are interfaces being removed, and > any time you get interface removal or signature change you need to > bump the SONAME, as we don't know if any package that depends on it > will break.
FTR, Francisco correctly pointed out to me that upstream has not bumped SONAME. This means we have an issue at hand here, upstream removed interfaces and should have bumped its API, we as the Debian maintainers can introduce a "distro specific" new version (do the bump ourselves) but that is not recommended and should only be the last resort[0]. Our ideal way forward here is contacting upstream, exposing the issue and asking for a new release with the correct bump, especially since this is likely to be an oversight by them. Can you open an issue on their issue tracker? > For reference: > https://www.debian.org/doc/debian-policy/ch-sharedlibs.html An extra reference which is very on point to this issue: https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#upstreamconcerns [0] I can see one argument being made that we could avoid the distro bump even by rebuilding the rdeps (just like a transition) but without the bump, thus basically "hiding" the backwards compatibility breakage, the risk here being that things built outside our official repos might inadvertently break when linked against the new package. In the end, if upstream does not provide a new release with a bump, we will have to evaluate which will be the alternative with less downsides. Regards, -- Samuel Henrique <samueloph>