Hi Afif,
On Sat, May 09, 2015 at 01:30:23PM -0700, Afif Elghraoui wrote:
> >>The other dependency seems to be a strange
> >>case. It is mt19937ar[1] (I'm not 100% if this is the correct link,
> >>but I believe it is), which I thought was in Debian as the package
> >>libghc-mersenne-random-dev [2], but that looks to be a different
> >>implementation. I still need to look into this more, but if you know
> >>anything offhand about this kind of situation, that would help speed
> >>things up for me. In the kmer upstream source, it is the directory
> >>libutil/mt19937ar.
> >
> >If you need help on this please state explicitly. Otherwise I'd wait
> >for further reports of yours, OK?
> >
>
> Yes, I need help. I've done some more reading and the situation is that:
>
> - upstream uses an apparently modified version of the random number
> generator mt19937ar [1]
> - The developers of mt19937ar have a whole suite of implementations
> [2-3], and only some of them appear to be in Debian.
> - mt19937ar is apparently not one of those versions that are in
> debian, but given that it is modified anyway, I'm not sure what
> should be done.
>
> Should I just leave the included copy in there?
This is the kind of questions that could be thrown at the
debian-ment...@lists.debian.org list. On the other hand for the moment
we might go with the changed code copy. Please document your research
results (= the text above) in a file debian/README.source. This will
save other people some work once somebody might consider doing the
removal of the code.
> For kazlib, I have a slight concern. The version in Debian is newer
> than what was bundled in the source (not by much: it looks like 1.21
> vs 1.20), but I have seen while grepping the kmer source comments
> like "My hacked kazlib returns pointers". Should I rely on the
> package's tests to pick up and potential problems resulting from
> this?
>From my point of view the tests are designed to reproduce expected
results. A software should not break if a depencency is upgraded. The
later is a totally normal thing and happens all the time. So if you do
not have any strong reasons to assume that the newer versions might
create any trouble I think this is OK.
> I suppose this is one of those cases where it helps to have a
> responsive upstream developer. But I suppose I can also compare the
> bundled version with kazlib upstream's v1.20 and see if there really
> are changes and, if so, whether those have been included in v1.21.
I will not stop you from doing this but as I said I would trust the
softwares test suite. Strongly speaking you would need to evaluate any
libc version bump if it affects your package.
>
> >In any case I have added kmer and libkmer-dev to the bio and the bio-dev
> >task respectively.
>
> Thanks. I have created the ITP [4] and somehow managed to mess it
> up. I inadvertently left out the X-Debbugs-Cc (?) field when copying
> the text into an email and so debian-devel and debian-med got left
> out of the recipients. I haven't yet looked into how to fix this
> besides just forwarding the email to these two lists.
Manually forwarding is fully sufficient. Its just to propagate the
information to the list.
Thanks for your work on this
Andreas.
> 1. http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html
> 2. http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html
> 3. http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/eversions.html
> 4. bugs.debian.org/784863
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150509221342.ga5...@an3as.eu
