[Debian-med-packaging] r17340 - trunk/packages/velvet/trunk/debian

[Tim Booth]

Hi Andreas,

OK, in that case please keep my extra rm statements in dh_clean but for
all other cases we'll stick to Debian convention.  I'll not do any
further commits unless you ask me to.

Cheers,

TIM

On Mon, 2014-06-30 at 12:27 +0100, Andreas Tille wrote:
> Hi Tim,
> 
> On Mon, Jun 30, 2014 at 11:57:00AM +0100, Tim Booth wrote:
> > > What do you mean by "VelvetOptimiser should be added to Debian"?  Do you
> > > have some separate packaging?  I vaguely remember that we discussed this
> > > previously (to lazy to seek the archive - seems you have better
> > > information anyway).  If you have some packaging it would be great if
> > > you could inject this as well into VCS and I'll upload to new.
> > 
> > I did this shortly after pushing the Velvet changes.  I think the
> > package is close to being fit for Debian.
> 
> Yup.  I just filed the ITP.
>  
> > > Any reason to kick the *.pdf files from the source archive?
> > 
> > Both PDF files rebuild from LaTeX source during the build.
> > 
> > > > +	find -name '._*' -delete
> > > 
> > > These files should not be in the uploaded source tarball anyway.  I'd
> > > recommend just sticking to the source tarball in the Debian archive
> > for
> > > md5sum identical source tarballs.
> > > 
> > 
> > I'm wanting my packages to build from pristine upstream tarballs unless
> > I absolutely have to repack them.  I know you always want to
> > scrub/repack the upstream tarball,
> 
> It is not only about me but rather ftpmaster requires us to remove stuff
> that is considered non-free.
> 
> > but I really want to have a source
> > package that can build the same binary debs from the unmodified
> > upstream, which is why I leave in the extra rules in dh_clean.  Given
> > that they are harmless I'm hoping you can leave them in.
> 
> Yup, they are really harmless and I see no need to kick them out.  I was
> just wondering whether it might reduce your maintenance work if you
> would rely on the Debian package source (which you are doing anyway if
> you take over Ubuntu packages).  But if you did this intentionally that's
> perfectly fine for me.
>  
> > Actually, the whole Files-Excluded mechanism seems redundant to me, when
> > one can simply do:
> > 
> > uscan && uupdate && cd <new pkg dir>
> > dh_clean
> > cd ..
> > tar --exclude=debian -cvaf <pkgname_ver+dfsg.orig.tar.xz> <new pkg dir>
> > 
> > Otherwise, I have to remove the .pdf files under Files-Excluded and then
> > again under dh_clean because they are rebuilt by dh_auto_build.  Surely
> > easier to put all cleanup under dh_clean?
> 
> Well, *if* you are cleaning up the files excluded in Files-Excluded
> *then* it looks a bit redundant.  But even then I prefer FIles-Excluded
> since your way to create the upstream tarball is not a "default" way and
> requires extra caution for the developer who is used to just call uscan.
> Moreover the tar in uscan is setting some extra options to get some more
> uniqe tarballs (--owner=root --group=root --mode=a+rX) which I consider
> useful and would always forget if I would do what you are suggesting.
> In shout:  I prefer the most straightforward default way via uscan if
> any possible.
>  
> > > > +	rm -rf data.tar.*
> > > >  
> > > > -override_dh_auto_build :
> > > > +build_long_versions :
> > > > +	touch zlib
> > > > +	#Make _long version
> > > > +	dh_auto_build -- LONGSEQUENCES=Y OPENMP=Y velveth velvetg OPENMP=1 CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
> > > > +	mv velveth velveth_long ; mv velvetg velvetg_long
> > > > +	#Make _63 kmer version
> > > > +	dh_auto_build -- MAXKMERLENGTH=63 velveth velvetg OPENMP=1 CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
> > > > +	mv velveth velveth_63 ; mv velvetg velvetg_63
> > > > +	#And also one with both options
> > > > +	dh_auto_build -- MAXKMERLENGTH=63 LONGSEQUENCES=Y OPENMP=Y velveth velvetg OPENMP=1 CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
> > > > +	mv velveth velveth_63_long ; mv velvetg velvetg_63_long
> > > > +
> > > > +override_dh_auto_build : build_long_versions
> > > >  	touch zlib # prevents the zlib in the ‘third-party’ folder to be built.
> > > >  	dh_auto_build -- OPENMP=1 CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
> > > >  	dh_auto_build -- color OPENMP=1 CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
> > > > +	#Pack the examples
> > > > +	tar -cvaf data.tar.xz data
> > > 
> > > Could you please explain the role of this data.tar.xz?
> > 
> > Oops - this should be included in the examples package in place of the
> > data folder.  I missed that fix out.  In the current package, the files
> > in this folder get individually auto-gzipped by dh_compress, to make use
> > of them the user needs to copy the whole directory and then run "gunzip
> > *".  It makes more sense to me if the user just has to extract a tarball
> > with the files in, so I think that is what should ship in the package.
> 
> So you think that `tar xaf *` is more easy than `gunzip *.gz` ???  Hmmm,
> IMHO that's a weak reason to do some means which look to me like some
> unmotivated deviation from what I usually see in Debian packages.  Would
> you really insist on it or could we just provide the single compressed
> files?
>  
> > > >  	dh_install
> > > > -	rm -rf $(CURDIR)/debian/$(pkg)/usr/share/velvet/contrib/MetaVelvet-v0.3.1/obj
> > > >  	# remove extra copies of GPL
> > > >  	find $(CURDIR)/debian -type f -name 'LICENSE*' -delete
> > > > +	#MetaVelvet should be scrubbed, and VelvetOptimiser is now separate.  Note that these
> > > > +	#will not have been installed if this was a binarry-only build.
> > > > +	[ ! -e debian/velvet-example/usr ] || \
> > > > +	  rm -r debian/velvet-example/usr/share/doc/velvet/contrib/MetaVelvet*
> > > 
> > > May be it is sensible to drop MetaVelvet from the source tarball at all
> > > and add it to Files-Excluded.  What do you think?
> > 
> > Yes.  Not sure why I ever did it like that.
> 
> I think I'll exclude MetaVelvet from upstream source since it just seems
> to add extra useless bytes to the source package which we are
> repackaging anyway.  I'll also exclude the pre-rendered PDFs since if
> these are recreated anyway we get into trouble if somebody wants to build
> the package twice in a row.
>  
> > > To rephrase my question from the beginning:  Where will this separate
> > > VelvetOptimiser be?
> > 
> > Patience, Andreas, patience!  I can't type SVN commands as fast as
> > you! :-)
> 
> May be you do and I had just opened my mail draft before realising that
> there was another commit from you. :-) 
> 
> Kind regards
> 
>         Andreas.
> 

-- 
Tim Booth <tbooth at ceh.ac.uk>
NERC Environmental Bioinformatics Centre 

Centre for Ecology and Hydrology
Maclean Bldg, Benson Lane
Crowmarsh Gifford
Wallingford, England
OX10 8BB 

http://nebc.nerc.ac.uk
+44 1491 69 2705