Re: appropriate architectures for packages
On 9/1/06, elw@stderr.org <elw@stderr.org> wrote:
> 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?
I tend to think, for most packages, that not being built on an
architecture where they *can* be built is a bug in the package.
In other words, lack of upstream support (by not providing an
appropriate configure script or whatever) might be a good reason not
to build it on certain arches. I believe that ROOT's configure script
(which is hand-written, not autotools-generated) doesn't support much
on Linux beyond the triumvirate of i386/amd64/powerpc, for instance.
(Maybe also ppc64, I'm not sure.)
For these heavy scientific packages, I'm not sure it makes too much
sense for the Debian maintainer to try porting it to "weaker" arches
if upstream's source won't even build there without a serious porting
effort. (Granted, I did so with Cernlib, and I even had to screw
around with Imake config files to do so (yuck!) but I don't think I
would do that now.)
One justifiable reason for not having the package build on a platform is
an unsupported, buggy compiler toolchain - but I don't think you'll run
into that on m68k, mips, et al.
You'd be surprised how many g77 compiler bugs I've run into on m68k
while maintaining cernlib.
Another reason to keep building the package - someone may want to build a
piece of embedded kit around it.
Hmm, an embedded Debian-based scientific workstation. That could be a
neat idea... I could see manufacturers of smart oscilloscopes and
other electronics doing that as a value-added thing.
regards,
--
Kevin B. McCarty <kmccarty@princeton.edu> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
Reply to: