Re: appropriate architectures for packages

[Thomas Walter <t.walter@nefkom.net>]

Hello,

On Fri, 2006-09-01 at 06:35, Carlo Segre wrote:
> Hello All:
> 
> One of my main goals for contributing to Debian was to bring more 
> scientific software to the project in an integrated way. I am happy to see 
> the efforts on GEANT and ROOT and other important science related software 
> but I have been running up against a serious issue for packages which are 
> resource hungry and i would like to hear others' ideas about the subject.
> 
> For example, my package, fit2k, is a peak fitting GUI program which uses 
> wxgtk and the boost libraries.  This is a very time intensive package to 
> compile and it has been known to hang some of the buildds for many many 
> minutes, resulting in a failed build.  This begs the question of whether 
> the fityk package is of any real value to architectures such as m68k, arm 
> and even mips where processors are older and not often used with graphical 
> desktops.  I am working on other packages for crystal structure solution 
> which require even more resources to run effectively and this problem will 
> only get worse.
> 
> I am tempted to just not even bother having the buildds try to build for 
> these architectures because the likelihood that someone will ever actually 
> _use_ fityk is vanishingly small even though it is possible to do so (in 
> principle).  However, I feel a bit guilty about excluding them.
> 
> I apologize for the somewhat incoherent discussion but the crux of my 
> question is this:
> 
> At what point does it make no sense to expend a lot of effort to build a 
> package on architectures where the are not likely to be used (or even 
> usable)?  Just because it _can_ be built on a particular architecture 
> does it _always_ make sense to do so?
> 

>From my point of view,
packages and applications being an overkill for an architecture/cpu when
"used" make no sense to build.
When the package making is nearly an overkill, but the final product is
at least usable by some degree [see previous replies], it may make sense
to build the package.
Just an idea: may cross-compilng help here and only build the final
(testing and stable) version in the real environment?.
Or just don't build automatically, but implement a way to signal the
buildd when to do so?
In addition, at least a reasonable large package is a very good stress
test for the compiler suite on that architecture to bugs in the compiler
suite.  Thus, building from time to time make also sense.

Cheers,
Thomas