[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [MoM] Re: kmer-tools



On Sat, May 09, 2015 at 04:10:15PM -0700, Afif Elghraoui 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.  I applied this diff to
Debian's mummer version 3.23 and this is now part of the official Debian
package.  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.
 
> >Thanks for your work on this
> 
> Of course. I myself would like to use this package.

Sure.  That's the best motivation to create the best possible package.
:-)
 
> 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?

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.

Kind regards

        Andreas.

> 1. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static

-- 
http://fam-tille.de


Reply to: