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
Reply to: