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 abundance of. 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 architecture? 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) Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]