[MoM] Re: Bug#784863: Debian package for kmer
Hi Afif,
I just like to pronounce how happy I am that you deal that
professionally with the packaging. I'd consider this the most
relaxing MoM project from a mentors perspective since you are
dealing in exactly the same manner I consider the correct way.
No further comments needed.
Thanks a lot
Andreas.
On Tue, May 19, 2015 at 11:03:45PM -0700, Afif Elghraoui wrote:
> Thanks for your reply. Please see inline:
>
> On الثلاثاء 19 أيار 2015 07:15, Brian Walenz wrote:
> >I'm a little slow on packaging up a release, sorry. It's on the to do
> >list with a decent priority, but not getting much time yet. The paying
> >projects are being unruly.
> >
>
> No problem.
>
> > From the kmer repo, I've created four releases by removing select top
> >level directories. For 'meryl' the directories are:
> >
> >Make.include
> >Make.rules
> >Makefile
> >README.compiling
> >README.meryl
> >configure.sh
> >libbio
> >libkmer
> >libmeryl
> >libseq
> >libutil
> >meryl
> >
>
> Thanks; this is very helpful. README.meryl is not on sourceforge, though. At
> least not that I saw.
>
>
> >No changes to Make* are needed. This is the package needed for
> >wgs-assembler. The other three are for ATAC, ESTmapper and sim4db
> >(which exists already).
> >
> >I've wanted to get rid of kazlib for a long time, and I think it is only
> >used by the atac package. Before you expend too much effort on
> >modifications, lets see if the meryl component will compile without it.
>
> I can verify that it does.
>
> >IIRC, it's used only in class 'bigQueue' in libutil. I wanted to
> >replace it with STL, but last time I looked, it wasn't a drop-in
> >replacement.
> >
> >The test suite(s) are probably quite low level, and not very good. A
> >functional test should find any major problems. I can't think of any
> >gotchas for reviving the tests though.
> >
>
> Ok, so I guess I'm all clear for tackling that.
>
> I'd like to lay out the full status, even though some of these items are not
> for the short-term. The short-term package looks like it will just provide
> meryl so that we can climb the dependency chain to wgs-assembler and other
> packages that use it. The rest of the code requires a little clean-up as I
> understood from you.
>
> * Short-term plan for first version of the package -- meryl only
> I can put this through on my own without additional action from your side
> (but the README.meryl file would be nice to have). I would work on the
> following:
> - build shared libraries rather than (or in addition to) static, as
> preferred for official Debian packages [1]. If you think this isn't a good
> idea, there is potentially some flexibility here.
> - create man pages for executables
>
> * longer-term plan -- remaining components + general improvements
> This part can wait until you complete the clean-up you mentioned in your
> first message. The steps here for me are:
> - include the remaining components and, same as for meryl, make shared
> libraries and man pages
> - You have a copy of mt19937ar in your distribution, which as of now is
> not packaged in Debian. I haven't checked to see if you patched this code or
> if it's an unmodified copy. At some point, mt19937ar would need to be a in a
> separate Debian package that kmer would just depend on.
> - fix test suite. I will also see how well this goes for meryl. If it
> doesn't take too long, I can have it be part of the package-build process.
>
>
> Thanks and regards
> Afif
>
> 1. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
>
> --
> Afif Elghraoui | عفيف الغراوي
> http://afif.ghraoui.name
>
>
> --
> To UNSUBSCRIBE, email to debian-med-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 555C23C1.1000107@ghraoui.name">https://lists.debian.org/[🔎] 555C23C1.1000107@ghraoui.name
>
>
--
http://fam-tille.de
Reply to: