Re: buildd/porter/maintainer roles again
* Russ Allbery <rra@debian.org> [100714 19:00]:
> "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'm regulary looking into mathematical software and I know too well that
software written by scientists and especially mathematics tends to be the
worst software thinkable. (I guess there are two reason why one creates
good software: not being able to cope with needlessly complex stuff and
love for clear sotftware. Scientists are usually able to cope with every
complexity and love their specific field of science instead).
> 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.
My argument is that all our obscure architectures are helping here.
Things only working by pure coincidence do not usually tend to break
some point in the future anyway. It's an investment now that will
cause many problems not show up on the more common architectures in the
future.
Bernhard R. Link
Reply to: