[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ongoing build problems with fityk on arm



On 06-09-28 21:49 -0500, Carlo Segre wrote:
> On Thu, 28 Sep 2006, Wookey wrote:
> 
> >On 06-09-17 10:52 -0500, Carlo Segre wrote:
> >>
> >>The question is this.  Is fityk really a package that is useful for the
> >>arm architecture?  Only those who use arm can tell me this.  If it isn't
> >>maybe I should exclude arm from the architecture list or the package can
> >>be marked "not-for-us".  I don't even what to try porting it myself using
> >>leisner as that machine has only 64M or RAM and I am sure that it will be
> >>painful if even possible.
> >
> >A quick read of the decription suggests that a vanishingly small part
> >of the populace would want to run this package on arm. I can think of
> >any sensible reason to want to do diffraction pattern analysis on an
> >arm box, although in theory someone might need some nonlinear
> >curve-fitting software.
> >
> >If it uses a lot of floating point (which seems likely) then it really
> >would be bonkers to run it on arm. I'd be perfectly happy to have it
> >marked 'not-for-us'.
> >
> >There is a whole class of software for doing various sorts of
> >numerical analysis that are not really appropriate for arm, but 'there
> >isn't any point' has not to date been considered a justification for
> >not including something in an architecture.
> >
> >There would be some benefit from a discussion about defining a set of 'no
> >point on low-powered architectures' packages.
> 
> I would welcome such a discussion, as would a couple of other DDs I have 
> been in contact with.  My position is that we could designate packages was 
> suitable for different classes of boxen:  workstation, server, etc ( I 
> would have to think hard of other categories) and use that as a guideline 
> for applying the not-for-us tag.  i am sure that there are other ways to 
> lay out such categories.

'Embedded' is the other obvious class in that hierarchy. I'm not sure
that 'workstation' is sufficient here. There are arm-based
workstations, but you still wouldn't want to run numerical analysis
software on them.

There is a benefit in building these packages on arm, just because it
ensures the sort of code quality which means they can be, but that has
to be weighed against the resources it takes. 

I am in favour of package maintainers such as yourself agreeing with
the arm porters that a number of such NA packages are marked
not-for-arm (and possibly m68k on the same basis?). However I don't
think we should start doing that wholesale without a wider discussion
to see if anyone objects violently.

I will post to -devel about this.

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/                 play: http://wookware.org/



Reply to: