[Debian-med-packaging] Tim - don't update the archive ... qiime Re: [med-svn] r7572 - trunk/packages/qiime

Andreas Tille andreas at an3as.eu
Tue Aug 30 12:55:04 UTC 2011

On Tue, Aug 30, 2011 at 10:55:17AM +0100, Tim Booth wrote:
> I'm sorry, but not surprised, to hear that Qiime is being troublesome.

There is no need for beeing sorry.
> To re-iterate one point, as far as I can tell all the various CDBS
> plugins and python-support/python-central/python2 helpers for DH all
> just end up copying the various Python libraries
> to /usr/share/pyshared/qiime.  There is no special magic or byte-code
> compiling going on, and although you can try to produce a tidy looking
> rules file, the package is never going to be neat simply because Qiime
> is a mess.

Well, finally it is not about having a nice looking rules file but
something which builds a proper package.  The current packaging stuff
in branches/lucid does not build in a Debian unstable chroot:

mkdir -p debian/python-module-stampdir
set -e; for buildver in 2.7 2.6; do \
                cd /tmp/buildd/qiime-1.3.0 && cd . && \
                        python$buildver setup.py build \
                        --build-base="/tmp/buildd/qiime-1.3.0/./build"; \
/bin/sh: 3: python2.7: not found

> So Qiime is inevitably going to need a hand-crafted rules file, but if
> the starting point for that file is "dh --with python2" then I'm unable
> to use it on Bio-Linux just now.

There is no law to use dh in favour of cdbs and we should focus on
something which works on both Bio-Linux and Debian unstable.  While I
continue to fail why dh should not be possible I need to trust you here
because I have no experience with Ubuntu.  The only thing I know is
that the python-central author himself is currently filing bug reports
against packages which are using this tool (and he is more on the
Ubuntu side of development) and thus it seems to be very reasonable
to use python-support (with cdbs or dh) instead of python-central.

I tried both starting from your rules file but both failed at some point
and my todays free time slot for this research is finished now.

> I think it would be really helpful if
> someone could try building the package with "python2"

This is what you can find in trunk.  For me it builds a quite reasonable
package and it does it without any nasty tricks I needed to apply with
the other tools.  Before I try to fix the "old style" rules files to
work under unstable - could anybody with a Ubuntu (Lucid??) system try
to have a look into this.  Perhaps there is a simple way to get this
running.  Alternatively any fix for the branches/lucid rules file to
build under unstable is equivalently welcome - we just want a package
which works on both (no matter what building tool is used).

> and then with
> older "python-support" and see what changes actually result in the
> final .deb.  I'd wager not much.  I can do this myself, but it's not a
> priority for me.

I perfectly accept your different preference.

> > > So, we should really set the message across that Debian has the
> > > same qiime that Bio-Linux has.
> Qiime mostly uses its dependencies for the heavy lifting, so the crucial
> thing is to have consistent versions of the dependent packages.  I thing
> progress here has been very good.

In this case we might condier setting '=' in the Depends (rather than
> > If I remember right the previous upload was refused by ftpmaster because
> > of improper handling of conflicts with denoiser.  
> Oops - I hoped I'd done this properly.  Qiime 1.3 should cleanly replace
> and provide the now obsolete denoiser package.  Any idea where I went
> wrong?

I might have mixed up things with pynast which was renamed from
python-pynast.  Here the Conflicts/Replaces/Provides was missing. 

Kind regards


PS: BTW, Debian has not (yet) the package fasttree which was mentioned
    in Recommends.  Should we possibly work on this first?


More information about the Debian-med-packaging mailing list