Re: Request to review and upload libvhdi_20201018-1
Hello, On Tue, 15 Dec 2020 at 08:40, Raphael Hertzog wrote: > If we don't have packages affected by the symbol removal (which looks like > to be the case given that all packages are still building) then we don't > need to bump the SONAME and we don't need any transition. Feel free to > upload to unstable right away. > > We don't have to care about programs manually compiled by the user, those > are outside of our control. And honestly, we're not speaking of a popular > library here so... Agreed and uploaded! -- Samuel Henrique
Re: Request to review and upload libvhdi_20201018-1
On Fri, 27 Nov 2020, Samuel Henrique wrote: > For reference, this was the ticket: > https://github.com/libyal/libvhdi/issues/15 > > I thought about this, as we have the option of performing the upload > without a transition. My conclusion is that we should get the opinion of > the release team on this, to lean on the safer side, so my suggestion is to: > Upload what we have now to experimental; > Create a bug for the release team explaining the issue and asking if they > want us to do a transition or if just the binNMUs are fine. > > Views from the rest of the team are welcome :) If we don't have packages affected by the symbol removal (which looks like to be the case given that all packages are still building) then we don't need to bump the SONAME and we don't need any transition. Feel free to upload to unstable right away. We don't have to care about programs manually compiled by the user, those are outside of our control. And honestly, we're not speaking of a popular library here so... Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Request to review and upload libvhdi_20201018-1
Hello all, We talked to libvhdi upstream, > in short, soname bump won't happen yet and > he says "Checking with git whatchanged -p include/libvhdi.h.in I don't > see any > mayor API (and therefore ABI) changes in the last ~4 years; a couple of > functions added and a couple of non-functional write functions were > removed.". > For reference, this was the ticket: https://github.com/libyal/libvhdi/issues/15 > Samuel, would you like me to request a transition slot for libvhdi > I thought about this, as we have the option of performing the upload without a transition. My conclusion is that we should get the opinion of the release team on this, to lean on the safer side, so my suggestion is to: Upload what we have now to experimental; Create a bug for the release team explaining the issue and asking if they want us to do a transition or if just the binNMUs are fine. Views from the rest of the team are welcome :) Regards, -- Samuel Henrique
Re: Request to review and upload libvhdi_20201018-1
Hello team, We talked to libvhdi upstream, in short, soname bump won't happen yet and he says "Checking with git whatchanged -p include/libvhdi.h.in I don't see any mayor API (and therefore ABI) changes in the last ~4 years; a couple of functions added and a couple of non-functional write functions were removed.". I have locally rebuilt the reversed dependencies (pytsk and sleuthkit) on amd64, and everything was built correctly, both in testing and in unstable. Below the output of the reversed dependencies: $reverse-depends src:libvhdi Reverse-Depends * libtsk19 (for libvhdi1) * python3-dfvfs (for python3-libvhdi) * python3-plaso (for python3-libvhdi) * python3-tsk (for libvhdi1) * sleuthkit (for libvhdi1) $reverse-depends -b src:libvhdi Reverse-Build-Depends * dfvfs (for python3-libvhdi) * plaso (for python3-libvhdi) * pytsk (for libvhdi-dev) * sleuthkit (for libvhdi-dev) Samuel, would you like me to request a transition slot for libvhdi? Best regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
Re: Request to review and upload libvhdi_20201018-1
Hi Samuel, Samuel Henrique: > 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? sure, it's open: https://github.com/libyal/libvhdi/issues/15 > >> 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, > > Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
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
Re: Request to review and upload libvhdi_20201018-1
Hello Francisco, > 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. As I know you already have previous experience with sleuthkit, this SONAME bump will require a transition as well. For reference: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html I recommend reading the whole section and please feel free to reach out to me or to the list if you have any questions, Thanks for your work -- Samuel Henrique
Request to review and upload libvhdi_20201018-1
Dear security tools team, I prepared a new version of libvhdi, release 20201018. I am not allowed to push in official repository, so the changes are at: https://salsa.debian.org/fvcr/libvhdi if it is satisfactory, please review and upload. Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
