Re: [MoM] kmer-tools status update
Hi Afif,
On Tue, May 26, 2015 at 03:06:01AM -0700, Afif Elghraoui wrote:
> >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.
In this case I'd recommend using it.
> >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.
Good hint. If you provide a patch that is easily understandable I'd
happily apply this.
> >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.
Adding another binary package requires another new processing. While
*usually* this is only a short check (1-3 days delay) we have currently
at least two packages (fis-gtm and orthanc) that are hanging there for
several weeks for reasons I totally fail to understand (even an
ftpmaster ping hasn't triggered any action). I have seen new packages
dripping in slowly recently but since about 8-9 monthers new processing
is heavily delayed for reasons I don't know. I hope this will change
in a decent time frame - usually it is a lack of manpower and bothering
an overworked team with questions does not enable them to work more
quickly - so I did not used this option (out of previous experiences).
I'll take Debian Conference as a chance to find out.
> If these additional modifications can be easily added later, I say please go
> ahead with the upload.
If you stick to this under the circumstances above I'll upload.
> >Kind regards and thanks for your thorough work on this
>
> Thanks for all your help in speeding up the process :)
You are welcome
Andreas.
--
http://fam-tille.de
Reply to: