[Debian-med-packaging] What about MetaVelvet? (Was: r7427 - trunk/packages/velvet/trunk/debian)

Andreas Tille andreas at an3as.eu
Fri Aug 12 14:24:48 UTC 2011


On Fri, Aug 12, 2011 at 04:46:46PM +0900, Charles Plessy wrote:
> Le Fri, Aug 12, 2011 at 09:37:58AM +0200, Andreas Tille a écrit :
> > On Fri, Aug 12, 2011 at 04:09:45PM +0900, Charles Plessy wrote:
> > > Le Fri, Aug 12, 2011 at 08:52:39AM +0200, Andreas Tille a écrit :
> > > > On Fri, Aug 12, 2011 at 03:33:03PM +0900, Charles Plessy wrote:
> > > > > > Additional question:  I somehow tend to keep on repackaging velvet to avoid
> > > > > > the copyright hell of zlib.
> > > > 
> > > > What about this one?
> > > 
> > > I think that it is completely up to Tim.  If the copyrights and licenses were
> > > documented, we would benefit from simplifying the package and use the pristine
> > > upstream sources.
> > 
> > I think they are not according the mail you sended yesterday in the
> > thread.
> 
> Exactly: by ‘if they were’ I wanted to mean ‘if somebody would volunteer’.

I do not volunteer for the moment.  So I revised debian/copyright,
stripped the zlib related part again and made get-orig-source less
confusing.  I also did not stripped MetaVelvet any more.

However, when having a look at 

/tmp/velvet_1.1.05~nozlibcopy/contrib/MetaVelvet-v0.3.1$ make -n
rm obj/*.o obj/dbg/*.o 
cd ../../third-party/zlib-1.2.3; ./configure; make; rm minigzip.o; rm example.o
...
gcc -Wall -O3 -lm -o meta-velvetg obj/tightString.o obj/graph.o obj/run2.o obj/fibHeap.o obj/fib.o obj/concatenatedGraph.o obj/passageMarker.o obj/graphStats.o obj/correctedGraph.o obj/dfib.o obj/dfibHeap.o obj/recycleBin.o obj/readSet.o obj/shortReadPairs.o obj/scaffold.o obj/locallyCorrectedGraph.o obj/graphReConstruction.o obj/roadMap.o obj/preGraph.o obj/preGraphConstruction.o obj/concatenatedPreGraph.o obj/readCoherentGraph.o obj/utility.o obj/kmer.o ../../third-party/zlib-1.2.3/*.o

I noticed that *if* we would build MetaVelvet from this source we will
have to deal with our old problem.  So what would you prefer (for the
moment):

  1. Upload velvet as is without MetaVelvet builded
  2. Fix building MetaVelvet and release it in a separate
     binary package.

Kind regards

        Andreas.


 
-- 
http://fam-tille.de



More information about the Debian-med-packaging mailing list