[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MBF: don't build against libatlas3-base if possible

Hi Ian,

On Wed, Oct 30, 2019 at 01:17:20PM +0000, Ian Jackson wrote:
> Hi.  I would like to congratulate you on your work so far.  I am no
> expert on this area but from what I read, I want to encourage you :-).

> I think it's important to give the MBF recipients a clear set of
> instructions on what to change.  And to assume that they may not know
> what they are doing :-).

As discussed here, we need to analyze the rdeps of libatlas3-base
case by case because there may be some special situations:
(/me proposed to drop libcblas.so from libatlas3-base)

Following that bug, I've studied two packages and provided patches for them:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943828 (altree)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943827 (meep)

So generally the maintainer should change the B-D
from < libatlas-base-dev > to < libblas-dev >. Sometimes the maintainer
also needs to patch the build system to force it link against -lblas
instead of -lcblsa (see 943828) for example.
> Your email gives clear instructions on what change to the .deb is
> wanted:
> > [...]  Ideally any program that needs BLAS/CBLAS ABIs should link
> > against libblas.so.3 instead of libcblas.so.3 (note the char "c" in
> > middle)
> But it is not clear to me how this should be achieve in a source
> package which currently build-depends on libatlas3-dev.  Can the
> build-dependency simpy be swapped out ?  If so, to what ?  Or are
> other changes typically needed ?

* A build system that supports many different BLAS implementations should
  be able to deal with -- the maintainer just needs to change the B-D.

* When the build system unconditionally links against -lcblas, the
  maintainer needs to patch it into -lblas

* If the package is sensitive to BLAS precision, or BLAS speed,
  the maintainer may optionaly add this for the binary package:
    Recommends: libopenblas-base | libblis2 | libatlas3-base |
	  libmkl-rt | libblas3 | libblas.so.3

  If the reference blas (i.e. libblas3) triggers FTBFS due to
  numerical precision problem, building with a high performance BLAS
  is fine, but the maintainer should carefully check the resulting
  package and avoid unexpected linkage such as -lcblas, -latlas, -lblis,
  -lopenblas, -lmkl, etc.

* If the program needs implementation-specific features, no change
  would be required. For example, currently Julia needs some specific
  features of openblas (openblas_set_num_threads etc) although it
  can be disentangled with some effort..
> (Please forgive me for writing this mail without having actually
> looked at any affected source package.)
Nevermind. The MBF title looks short but the underlying problem is
not that simple and straightforward.

> > @Andreas, can we add this point to science-team policy?
> I will leave this to Andreas.  But if Andreas and the science-team
> agree with you, then this is clearly a candidate for a lintian
> warning.  You probably want to file a bug against lintian.

I didn't even think of adding a lintian check for this purpose.

We can add two lintian WARNINGs:

  W: linkage-against-specific-blas-lapack-implementation

    triggered when detected any specific BLAS/LAPACK implementation
    in shlibs:Depends . The package should link against the standard

	  libblas3 | libblas.so.3,
	  liblapack3 | liblapack.so.3,

    In order to enable the update-alternative mechanism.

  W: linkage-against-libcblas

    triggered when libcblas.so.* has been found in shlibs:Depends.
	that indicates the maintainer may have fallen into a trap.

I'll raise a discussion about this on -science and take further
action according to the result.

> Please keep up the good work.
> Regards,
> Ian.
> -- 
> Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.

Reply to: