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: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943712 (/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 blas/lapack: 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 <ijack...@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.
