[Debian-med-packaging] r7374 - in trunk/packages/qiime: . 1.3.0_ubuntu_lucid/debian 1.3.0_ubuntu_lucid/debian/patches

[Andreas Tille]

On Wed, Aug 03, 2011 at 11:38:59AM +0100, Tim Booth wrote:
> For Qiime it just seemed easier to work from the old source package to
> get a working Qiime 1.3 DEB.

OK, fine for me - just thought about saving you some work.
  
> qiime/support_files/denoiser/FlowgramAlignment contains three Haskell source files plus a Makefile 
> to handle compile/clean.

Ahh, so it is also connected to denoiser ... which makes my point to use
a (please read *a* not *the current*) Debian package even stronger.
 
> > Is there really any need for duplicating this code instead of using the
> > Debian packaged version of denoiser?
> 
> The standalone Denoiser is obsolete, with the newest version of Denoiser
> being distributed within the Qiime tarball.  So I could have the qiime
> source package produce a separate denoiser DEB but then looking at the
> other functions of the Qiime components there is no real reason why
> Denoiser should be split out anyway.

There could be a reason in so far not to bloat a "small" binary arch=any
package with a lot of arch=all stuff.

> I think its existence as a
> separate package is purely due to the desire of the authors to write a
> separate publication for this component of the pipeline, and to
> demonstrate their denoising feature in contrast to the similar feature
> in the Ampliconnoise toolkit.

Thanks for the explanation.  I currently do not have much time to
investigate into this but if we are shipping one flavour of denoiser in
the qiime source package which is maintained, than we should definitely
drop the other (unmaintained) denoiser package.  If a denoiser in itself
does not make much sense outside qiime (which I can not tell) the split
into two binary packages is in fact disputable and I will not stubbornly
insist on it just to split into arch any/all parts.

> (Note that Qiime 1.3 is able to use the
> denoising feature from Ampliconnoise if that package is installed - this
> component is called Pyronoise and there was previously a standalone
> Pyronoise download, but no Debian package for it as far as I know).

Do you think such a package would make sense?

> > BTW, I really wonder for what reason denoiser and qiime are hanging
> > around in experimental.  Steffen, could you please comment on this.
> 
> The main issue as far as I know is that Qiime depends on non-free
> components for standard operation.

But non-free/contrib are orthogonal to experimental/unstable!

> UClust is the main offender.  For
> now, on BL, we just ship the offending binary within the
> "bio-linux-qiime" wrapper package.  As sequence clustering is a fairly
> common task, and Qiime is a priority tool for BL, I'm confident that at
> some point an alternative can be substituted and the whole lot will be
> suitable for inclusion in Main.

So the package should go perfectly to unstable / contrib.
 
> Denoiser is free, but as per my comments above I don't think it should
> be a separate package any more.

OK, as I said - you are the expert.  If you think nobody uses denoiser
standalone it makes no sense to provide such a package.  However, there
is some hint in your mail that there yould be a replacement (Pyronoise)
which - provided it would be packaged - could replace denoiser.  If this
is the case my (biased) point of view could speak for a separate package
and qiime could depend from denoiser | pyronoise.  Decide whatever might
make sense to your opinion.

In case we will realise that the relation between arch any / all parts
in the final package are not good we should probably decide for a split
qiime + qiime-common (or something like this) for the usual reasons
which apply here (feel free to bother me about this if it is not clear).

Kind regards

       Andreas.

-- 
http://fam-tille.de