Re: buildd/porter/maintainer roles again
* Charles Plessy <email@example.com> [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.
Things needing "porting" to work on all architectures usually include
- 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).
- undefined behaviour
Unaligned access is quite common. That's sad because in my experience
it's practically impossible to get it without getting into the "undefined"
part of the C specification. That usually means that just the next
compiler could have some optimisation that causes your code to go
Also note that it's not about "embedded arches where nobody will use
them", but about the "architecture you did not care about".
I doubt amd64 would have been possible without alpha fixing the
ubiquitous 64-bit-unreadiness for years.
Arm and mips might appear on laptops soon. And even the ones found in
NAS devices have speeds that ten years ago would have been high-end
Even the mainstream processors got more picky about alignment. Thanks
to vector operations and compiler optimisations using them sometimes
you can get problems with undefined behaviour that is otherwise only
visible by unaligned access causing SIGBUS.
> conclusion is that it would be harmless for the ports to ignore the package
We had this discussion already: show me a port that want to ignore packages.
If you as package maintainer want to ignore bugs in your package by
ignoring architectures showing them, then say it this way. And do not
claim a perspective you do not have.
Bernhard R. Link