[Debian-med-packaging] Bug#728650: Bug#728650: FTBFS on PowerPC, patch attached.

Adam Conrad adconrad at 0c3.net
Mon Nov 4 03:44:01 UTC 2013


On Mon, Nov 04, 2013 at 08:36:52AM +0900, Charles Plessy wrote:
> 
> Hmmer is a software for scientific computing.  Using it with AltiVec/VMX
> disabled on a recent PowerPC platform makes no sense from an economical
> point of view.

Sure, though previous versions had vmx disabled as well, that somehow just
didn't work out so well in the most recent upload without my patch.

> Also, if building with AltiVec/VMX is broken, it may be the symptom of a bigger
> probem.  How do we know if it the program works at all even if it builds with
> AltiVec/VMX disabled ?  We have no test suite and no sign of users of the hmmer
> Debian packages on PowerPC. 

I would be all for someone fixing the actual bug with building with AltiVec
enabled, though AltiVec isn't a baseline for Debian/powerpc, it could be
reasonably argued that certain packages can just warn in their description
that it's going to explode without it.  Runtime detection would be even
better, but hmmer doesn't seem to have any such fanciness currently.

> I would recommend to simply stop distributing it on PowerPC, and invest further
> work only if we have a user asking for it.

Well, if you make that argument, you may as well stop building it on almost
all arches, as most use the generic C implementation.  I think there's value
in building on all arches, even if you think your target audience might not
care, in that porting to multiple arches keeps the code a bit more clean and
sane and generally portable, plus if someone comes along on ARM, installs it,
says "man, this is kinda crap", they may well be inclined to do a VFP or NEON
port and contribute it.  That's a lot less likely if you just shun arches
that don't have an optimised backend available.

... Adam



More information about the Debian-med-packaging mailing list