Re: Patching fermi-lite to enable packaging libSeqLib
Hi Sascha,
On Wed, Feb 08, 2017 at 02:47:43PM +0100, Sascha Steinbiss wrote:
>
> > to package the latest version of freebayes (version 1.0.2 is in new,
> > latest upstream is 1.1) a new library libSeqLib is needed. I started
> > with the packaging[1] and managed to build it without the patched code
> > copy of fermi-lite. SeqLib upstream was doing some patching since bwa
> > and fermi-lite are using the same variable bseq1_t which is defined
> > differently. I patched fermi-lite in Git by renaming it to fml_seq1_t
> > (and some other code changes + additions by libSeqLib author).
>
> OK. This sounds like a reasonable change (as long as there are no other
> packages depending on it).
I have not found any further dependencies.
> > I have not yet uploaded fermi-lite since ariba depends from fermi-lite
> > and needs to be adapted to the patched fermi-lite (as I did in commit
> > 92be90993f020d5d2395f083a42a48cebd5bab49) and wanted to discuss this
> > here. While I have opened an issue at Github for fermi-lite[2] there
> > was no response until now.
>
> The change to ariba's C++ code looks OK to me.
Thanks for confirming.
> > What do you suggest to do? My proposal would be to upload the patched
> > fermi-lite as well as the patched ariba to experimental (which is
> > advisable in freeze anyway) and keep on working with libseqlib.
>
> Agreed as far as I am concerned. However, might one probably argue that
> the symbol clash is worth a RC bug? If so then it might even qualify for
> unstable? What do the others think?
Its defitely broken but as far as I can see it does not break any
existing package. So IMHO this does not qualify for RC. Since I intend
to backport freebayes and this backport also needs a fixed fermi-lite it
would be convenient to have it in Stretch but we can easily backport this
as well and so it does not have a practical negative effect for the user.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: