[Debian-med-packaging] uc-echo: build-dep on g++-multilib

Charles Plessy plessy at debian.org
Sat Apr 27 22:18:53 UTC 2013


Le Sat, Apr 27, 2013 at 08:01:17PM +0200, Thorsten Alteholz a écrit :
> 
> On Sat, 27 Apr 2013, Roland Stigge wrote:
> >I noticed that uc-echo can't be built on platforms without g++-multilib
> >(like powerpcspe) because of the build-dependency on g++-multilib.
> >
> >Further, -m64 is forced as a compiler option to enable allocating >4GB
> >of RAM.
> >
> >Would it make sense to enable build on platforms without -m64 being
> >unavailable (as on powerpcspe), or does uc-echo only make sense with
> >>4GB RAM allocations?
> 
> uc-echo is used to analyse data from NGS-hardware (Next Generation
> Sequenzing). One advantage of such hardware is that it is able to
> analyse lots of short fragments in parallel and thus being much
> faster than older algorithms. Unfortunately the error rate in
> NGS-data is higher and thus more data is needed simultaneously to be
> able to correct this and to get a final result with high accuracy.
> As the ECHO algorithm does not need some reference data, the need
> for RAM is further increased.
> 
> I am not an NGS expert but I think that useful work can only be done
> with uc-echo when lots of RAM is available. But maybe others can
> comment on this ...

Hi Roland, Thorsten and everybody,

my experience with programs related to high-throughput "next generation"
sequencers is that they are developed and tested only on amd64.  On the other
plaforms, sometimes they will work by chance, sometimes they will fail to
compile, and sometimes they will give wrong results.  I wouldn't invest much of
my time porting them unless there is a serious competitor to the amd64 platform
for bioinformatics computing.  Even in that case, we ought to get sponsorship
for that kind of work, because it is a huge undertaking, and it is risky: we
can not predict which will be the platform that will eventually replace amd64
for scientific computing.  The one taking the risk should be the hardware
vendor, not the Debian developers.  Of course, if you find it fun, just do it :)

Have a nice Sunday,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan



More information about the Debian-med-packaging mailing list