How should we deal with 'pointless-on-this-arch' packages?
In general debian builds everything for every architecture. This is a
very good plan and finds a lot of bugs.
However there are some packages which are clearly not sensible on some
arches. Numerical analysis software in general on arm is a good
example of this class. Arm hardware is generally slow and more seriously has no
floating point hardware (except very exceptionally).
No-one in their right mind would run numerical analysis on an arm box,
for any purpose other than testing that they could.
Now in an ideal world we would gratutiously build these packages
anyway, just to check that they do build on said architecture, but
there is a cost to doing this. Buildd time and archive space. Buildd
time particularly, for slow arches, is a resource we don't have a huge
So, 'is pretty much pointless' has not to date been deemed a reason to
mark a package 'not for us'. However, It seems to me that if the porters
_and_ the package maintainer agree that there really is no real point in
building a package for a particular arch, and it takes signifcant
resources to do so, that it is best to mark such packages 'not for us'.
However I don't think we should just start doing this unilaterally,
so I am posting here to canvass opinion. Should inappropriateness be a
criterion for deciding a package is not-for-us?
Should we perhaps have a more general mechanism than such ad-hoc
marking to indicate innappropriate combinations of package and
An example of this genre is fityk, which currently times out on arm,
trying to build large C++ files. It is curve-fitting software. It
could probably be built, but one wonders if it is worth the effort.
The author is happy to not have it built for arm.
I'm sure there are others in the same situation, although I have not
done extensive research to try and produce a list.
(cc: me - I'm not subscribed)
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://wookware.org/