Re: [MoM] kmer-tools status update
Hi Afif,
On Tue, May 26, 2015 at 01:20:19AM -0700, Afif Elghraoui wrote:
> >Hmmm, I can not parse this as a specific question to me - just ask if I
> >can help somehow. Regarding packaging shared libraries I personally
> >recommend using d-shlibs. There are some examples in our repositories
> >for instance bambamc, bamtools or snp-sites (just a random pick from my
> >poor mind with no specific order or preference)
>
> Thanks. These are good enough pointers for me to start trying something. I
> was mostly confused by having to mind the symbols and sonames. It looks like
> I should just build the .so files and take care of their placement in
> multiarch folders...at least, as a first step.
Yes. I like the fact that d-shlibmove makes it easy by simply
specifying "--multiarch" and that you do not neet to care whether
sonames are correct or not since d-shlibmove checks it for you.
Things basically turn out to be something like
d-shlibmove --commit \
--multiarch \
--devunversioned \
--exclude-la \
--movedev debian/tmp/usr/include/* usr/include \
debian/tmp/usr/lib/lib*.so
However, it seems there are no dynamic libraries provided since you do
only provide a libmeryl-dev package but no libmeryl<soname> package,
right? While the dynamic library package would be the high art of
packaging I would have no problems to follow the pragmatic approach and
go with the static linking for the moment. Finally we do not want to
leave our final goal to package wgs-assembler out of sight. Otherwise
you need to tweak the build system to use libtool and create dynamic
libraries.
> >>Moreover, the spacing is
> >>the same for the other two generated packages and I don't get this warning
> >>for them. Otherwise, the package is lintian clean.
> >
> >See my latest push. :-)
>
> Oh... I see. :facepalm:
:-) Yes, that simply happens...
> >I: kmer-tools source: duplicate-short-description meryl libmeryl-dev
>
> Done.
>
> >I: kmer-tools source: quilt-patch-missing-description kazlib.patch
> >I: kmer-tools source: quilt-patch-missing-description remove-kazlib.patch
> >
>
> Done.
Fine.
BTW, for lintian I recommend the following:
$ cat ~/.lintianrc
color=always
display-experimental=no
display-info=yes
pedantic=no
## show-overrides=yes
> >You might like to override
> >
> >I: kmer-tools source: debian-watch-file-is-missing
> >
> >with a comment to express the fact that there is no chance to write such
> >a file.
> >
>
> Lintian info recommended creating a dummy watch file with comments
> explaining the situation. I did that and hope it's ok with you (more details
> in my commit message).
Yes, that's perfectly OK.
> >I decide from time to time whether I fix things like
> >
> >I: meryl: spelling-error-in-binary usr/bin/existDB endianess endianness
> >
> >If there is a responsive upstream I send a patch.
>
> Fixing this involves renaming two of the source files. Is there an way to do
> that with quilt without essentially deleting it and creating it with a
> different name? I feel like upstream will laugh at me if I send in a patch
> to correct such a minor thing.
If you feel upstream will laugh at you than please do not mind spending
your time on this with quilt tricks. There is no sense in huntin down
any lintian info just for the sake of it. The maintenance burden (for
now and in future if possibly other Debian developers need to understand
your code) does not rectify just fixing spelling errors only because
lintian has detected them (there are possibly more undetected ones).
> >For things like
> >
> >I: meryl: hardening-no-fortify-functions usr/bin/existDB
> >
> >I never found a solution myself and consider this false positives. Feel
> >free to leave these untouched.
>
> I was able to resolve this. The dh_make debian/rules template had some
> extremely useful information in this regard.
Hmmm, interesting. I was always able to get rid of the relro *Warning*
when doing this. May be I need to review the rules files in future more
thoroughly. Thanks for hunting this down.
> >Please add the DEP3 headers to the patches since this is helpful for
> >other team members.
>
> Done (and sorry about that; I totally forgot about the quilt header thing).
No need to sorry about this. There are long standing developers who not
provide DEP3 headers. :-)
In short: If you confirm that you intentionally want to go with static
linking for now I'd go on uploading to the new queue.
Kind regards and thanks for your thorough work on this
Andreas.
--
http://fam-tille.de
Reply to: