Re: htslib: version 1.8 drops symbol cram_nop_decode_reset without bumping soversion
Le Sat, Apr 28, 2018 at 03:48:54PM +0200, Mattia Rizzolo a écrit : > On Fri, Apr 27, 2018 at 11:53:36PM +0200, Andreas Tille wrote: > > > I think we both agree that the discussion of upstream is technically not > > the best. > > Feels to me they just don't perceive the need for proper symbol > management, which is not particularly surprising. Well, on my side I am surprised since the htslib authors clearly aim at providing their library to a broad range of developers of bioinformatics tools. I think that if somebody would have time to prepare a patch, it would have good chances to be accepted. In the meantime, I think that updating the .symbols file without changing the soname is the solution with the best tradeoff between risk, extra work, and deviaiton from upstream. Have a nice week-end, -- Charles
Re: bart version 0.4.03
On Sat, Apr 28, 2018 at 07:54:57PM +, Uecker, Martin wrote: > > Fixed. Ready to be uploaded I think. Done - thanks for the preparation, Andreas. -- http://fam-tille.de
Re: bart version 0.4.03
Fixed. Ready to be uploaded I think. Best, Martin Am Samstag, den 28.04.2018, 21:14 +0200 schrieb Martin Uecker: > except I broke something again... Let me fix this first. > > Martin > > Am Samstag, den 28.04.2018, 21:10 +0200 schrieb Martin Uecker: > > Hi Andreas, > > > > I have upgraded the BART package to the latest upstream version. > > Can you please upload? > > > > Thank you! > > Martin
Re: htslib: version 1.8 drops symbol cram_nop_decode_reset without bumping soversion
Hi Mattia, On Sat, Apr 28, 2018 at 03:48:54PM +0200, Mattia Rizzolo wrote: > > I think we both agree that the discussion of upstream is technically not > > the best. > > Feels to me they just don't perceive the need for proper symbol > management, which is not particularly surprising. Yes, unfortunately not surprising. > > Do you think it is OK to stick to the current soversion anyway? > > If what they say is true, yes. > Please mention that reason in the commit you'll do to drop the line from > the .symbols file. What do you think about my alternative suggestion to reintroduce the function (which is empty anyway)? > Also, I see you added " cram_drain_rqueue@Base 1.8-1": you should simply > use the upstream version, without the debian revision there. Sure. I think this ends up in a build-error / lintian-error (??) anyway. I was just blindly applying the patch that was issued by the last attempt to build and discuss next steps first. Kind regards Andreas. -- http://fam-tille.de
Re: bart version 0.4.03
except I broke something again... Let me fix this first. Martin Am Samstag, den 28.04.2018, 21:10 +0200 schrieb Martin Uecker: > Hi Andreas, > > I have upgraded the BART package to the latest upstream version. > Can you please upload? > > Thank you! > Martin
bart version 0.4.03
Hi Andreas, I have upgraded the BART package to the latest upstream version. Can you please upload? Thank you! Martin
Re: htslib: version 1.8 drops symbol cram_nop_decode_reset without bumping soversion
On Fri, Apr 27, 2018 at 11:53:36PM +0200, Andreas Tille wrote: > you was involved in the discussion of the Github issue[2]. Right, I chimed in after I read your previous email here. > I think we both agree that the discussion of upstream is technically not > the best. Feels to me they just don't perceive the need for proper symbol management, which is not particularly surprising. > Do you think it is OK to stick to the current soversion anyway? If what they say is true, yes. Please mention that reason in the commit you'll do to drop the line from the .symbols file. Also, I see you added " cram_drain_rqueue@Base 1.8-1": you should simply use the upstream version, without the debian revision there. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
