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

[Andreas Tille]

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.

-- 
http://fam-tille.de