Re: [MoM] Re: kmer-tools
Hi, Andreas,
On السبت 9 أيار 2015 23:44, Andreas Tille wrote:
>>> >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 was concerned more about potential modifications of the bundled
>> code than the version upgrade alone, but I think you are right in
>> that the test suite should pick up any errors resulting from this.
>
> OK, that's a fair point. I recently had this point in the (not yet
> finished) mugsy package where upstream admitted to have patched the
> included code copy of mummer version 3.20 while Debian ships mummer
> 3.23. I did the following: Download mummer version 3.20 from upstream
> and create a diff from mugsy's code copy.
This is basically what I proposed to do before.
> I applied this diff to
> Debian's mummer version 3.23 and this is now part of the official Debian
> package.
While I still think the tests should pick up any errors resulting from
using a newer, vanilla release, I think the possibility of something
like this happening and eventually making its way upstream would be
worth doing.
> So to be sure you can at least check the diff whether kmer
> upstream has patched the lib to some extend. If there is no diff you
> are done - if not it might be worth inspecting it more deeply.
>
I will check. Like I said before, while grepping the source I found some
signs that this is likely the case.
>
>> About the shared/static library issue. I looked through the Debian
>> Policy Manual again and came across the section about static
>> libraries (Section 8.3) [1]. The exceptions listed there look like
>> they match this package's situation. Should I just keep the static
>> libraries as they are for early versions of this package?
>
> Just for the sake of interest: Which of the three items do apply?
>
I thought the second one and possibly also the third one. The second one
because the lack of versioning makes it difficult to say anything about
the interface's stability. The third one depends on what upstream would say.
> In general: While it makes perfectly sense to do the library packaging
> "the proper way" (TM) I think we could apply some pragmatism here and
> see what approach will be the more direct way to a usable package
> without any practical constraints. So if you think static libraries are
> OK - at least for the moment - I have no problem if you do so.
>
I think so. I'm hoping upstream will cooperate if he sees there is an
upload to the official archive.
I didn't get to work on the package today, but I just need to take care
of the manpages as discussed before.
Regards,
Afif
>> 1. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
Reply to: