Re: [MoM] kmer-tools status update
Hi Afif,
On Tue, May 26, 2015 at 09:24:58PM -0700, Afif Elghraoui wrote:
> >>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.
>
> Ok, I'll see what I can do.
This would be great.
> >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.
>
> I have tried the library packaging, but there is no soname and I am not sure
> how to assign one since I don't know the state of the interface and how this
> changes between different svn revisions.
>
> I have committed my attempts to the "sharedlibs" branch (or some similar
> name), leaving master in a working state. The sharedlibs branch does not
> build because an actual file is found rather than a symlink to the
> library+soname, as I describe in my commit message.
I checked this and while you correctly noticed that there is "some" option
to get a dynamic library this is not the libtool option which enforces a
clean library. The build in the sharedlibs branch fails since d-shlibmove
is requiring a symlink for the *.so file. Out of curiosity I checked on my
local machine
$ readlink /usr/lib/x86_64-linux-gnu/*.so | grep \.so$
libncurses.so
libldap_r.so
libpng12.so
so we do have counter examples to this (surely not build with d-shlibs)
and so it might be possibly to forget d-shlibs and move around the files
via usual dh_install but I think we should draw a cutting line here. I'd
(strongly) recommend to upstream using autoconf + libtool to get a proper
build system and we could live with the static lib for the moment.
> In this view, this looks like it will take a little time and some
> communication with upstream to sort out. Please upload the current state if
> it all looks good to you.
When doing some experiments with the sharedlibs branch I tried a simple
debuild after the build failed due to the d-shlibmove check. I realised
that the build in this case failed at some earlier (totally unrelated)
point. I think this is a sign that the clean target does not leave the
directory tree in the same state as before the first build which has the
effect that the package does not build twice in a row. This is
considered an error and there are people running checks on the archive
from time to time and file according bug reports. For the moment I do
not consider this a large enough problem to stop me from uploading to
new and so I did this. :-) I just wanted to prepare you about things
that might be necessary to do once the package will reach the package
pool but perhaps meanwhile the build system has changed and the
situation at this point will be different anyway and the problem might
have vanished silently.
Thanks for your good work on this complex package for a MoM project
Andreas.
--
http://fam-tille.de
Reply to: