Re: [MoM] kmer-tools status update
Hi, Andreas,
On الثلاثاء 26 أيار 2015 02:33, Andreas Tille wrote:
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
That looks great.
However, it seems there are no dynamic libraries provided since you do
only provide a libmeryl-dev package but no libmeryl<soname> package,
right?
I actually started doing this, but don't have a commit ready yet.
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.
This part isn't too bad, actually. The custom build system has a shared
library option that I was able to latch onto and make them with.
BTW, for lintian I recommend the following:
$ cat ~/.lintianrc
color=always
display-experimental=no
display-info=yes
pedantic=no
## show-overrides=yes
Good to know. I'll copy that.
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).
Ok. Yeah, I don't think it will be considered worth the potential
headache of breaking something inadvertently.
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. :-)
It might be helpful to add that command in the "managing patches"
section on the Debian Med policy. I was always following the steps there
when doing my patching. I know the New Maintainer's Guide has it, but
it's not easy to read two guides at once.
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.
Ok, so if you upload it now, how easy will it be to later add new binary
packages from this source-- like the shared library package and the
other components of kmer? I'm a bit eager to get in line at the new
queue since reading about how far it's backed up.
If these additional modifications can be easily added later, I say
please go ahead with the upload.
Kind regards and thanks for your thorough work on this
Thanks for all your help in speeding up the process :)
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
Reply to: