"Bernhard R. Link" <brl...@debian.org> writes: > * Charles Plessy <ple...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bpaa5792....@windlord.stanford.edu