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