Bug#963250: openblas: Please build on armel

[Sébastien Villemot]

Le dimanche 21 juin 2020 à 17:28 +0300, Adrian Bunk a écrit :
> On Sun, Jun 21, 2020 at 02:54:22PM +0200, Sébastien Villemot wrote:
> > Le dimanche 21 juin 2020 à 14:40 +0300, Adrian Bunk a écrit :
> > > Source: openblas
> > > Version: 0.3.9+ds-2
> > > Severity: normal
> > > Tags: patch
> > > 
> > > A debdiff for building openblas on armel is attached.
> > 
> > What’s the point of building openblas on armel? 
> > 
> > Openblas is a highly optimized BLAS library, which only makes sense on
> > machines with hardware floating point.
> > 
> > For armel, reference BLAS (as provided by src:lapack) is probably as
> > efficient.
> 
> I don't think "efficiency" is relevant when using either on armel hardware...

Sure. But the difference is that src:lapack is standard Fortran 77, and
should thus be well supported on armel. On the contrary, src:openblas
is full of hardware-specific hacks, assembly code and the like; and
upstream does not support armel.

So enabling it on armel could mislead users into believing that
openblas is supported and/or useful on their platform, which it is not.

Also, upstream will not help us if there is a regression, and the
package is likely to take forever to build given the low performance of
armel (building it is already very resource hungry on an recent amd64
machine).

> What I am interested in is that reverse dependencies behave 
> (and break) the same on armel as they do on armhf.

Note that since src:lapack and src:openblas provide the same ABI, the
recommended practice for packagers is to never explicitly (build-
)depend on openblas (or at most to put it second in an alternative, or
as a Recommends).

But in any case, I don’t understand why we should aim at identical
behaviour of armel and armhf in the field of number crunching. Those
two architectures are very different in that area, in a number of
respects, and this is unavoidable given the hardware differences.

So I personally see more inconvenients than advantages to implementing
this.

Maybe my co-maintainer Mo Zhou could weigh in?

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20200621/7376f14a/attachment-0001.sig>