[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request to review and upload libvhdi_20201018-1



> > 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>


Reply to: