Re: buildd/porter/maintainer roles again
"Bernhard R. Link" <brlink@debian.org> writes:
> * Charles Plessy <plessy@debian.org> [100714 02:15]:
>> In situations where nobody volunteers to do the work of porting leaf
>> packages for scientific computation on embedded arches where nobody
>> will use them,
> I'd rather think that is an indicator that a package is not suiteable
> for Debian because of poor quality.
I tend to agree in general, but it's worth noting that if there are any
legitimate cases here (things with low-level, fine-tuned assembly code or
the like for specific architectures), Charles is packaging the types of
things (high-performance scientific computing applications) that are most
likely to have such issues.
I suspect, though, that most of the cases he's running into are...
> - sources doing '#if' for all known architectures and having no working
> default pure-C implementation.
> While that is understandable for some low-level stuff not easily done
> in C (like the core of some languages), I've seen this more than often
> enough that some C or C++ project just tries to optimize code and lets
> the generic implementation bitrot (or had it never working).
...this, or at a more basic level, a build system that makes assumptions
about all the platforms it could "ever possibly" be compiled on.
It's sad how many scientific applications I've seen that do something
functionally equivalent to:
#ifndef __i386__
/* Code assuming amd64. */
#endif
One of the challenges that is particularly bad with scientific code is
that a lot of the authors are not coming from a programming background and
are not familiar with the commonly used methods for handling things like
this that are prevelant in the open source world. The code usually has
some cobbled-together build system that was written by some grad student
five years ago out of chewing gum and duct tape, which no one involved in
the project is willing to touch or understands.
In one sense, then, you're right: it's often badly written code, or at
least badly *packaged* code (the core scientific stuff is sometimes quite
pretty). On the other hand, that's just the state of maturity of that
field at this point, with some stand-out exceptions. If we want to try to
make Debian a strong platform for scientific computing, we unfortunately
have to figure out how we're going to deal with that type of upstream for
many of the packages.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: