Regarding having BLIS in a PPA (either Debian or Ubuntu, or does it matter?): on OpenSUSE there are the regular packages in the "official" repos, but there are also "1-Click" install files which prompt the package manager to both add an external package repo (the PPA in our case) and then install the package. Does something like this exist for Debian/Ubuntu? The upside of this would be not needing to get into the official repo but also making it easy for users to install and get updates. If we don't care about the second part then a bare .deb/.rpm would also suffice.

Does something like this exist for Debian/Ubuntu?

@devinamatthews According to this wiki, it appears that the answer is yes (see section "Adding Personal Package Archives (PPAs)"). However, this may not so much as capture new users as give some of the existing ones another installation option. The way I see it, if the person is willing to pre-configure their Ubuntu GUI package widget to download from, say, Nico's PPA, they would probably already be willing to go straight to GitHub, especially since the latter would allow them access too all configuration options, whereas a binary would restrict them to whatever choices the package maintainer made.

The "1-Click" thing is slightly different in that one can just have a link on a webpage that the user clicks on, and then everything is automated from there. Adding a PPA manually to Ubuntu is relatively much more of a PITA.

@devinamatthews Understood, sorry for that nuance being lost on me. (I've never used OpenSuSE.)

I myself am a Debian Maintainer (DM) so I have a fair idea of how things are working. A package gets into Debian if (a) it's popular enough for people to want it or (b) if another package depends on it. This approach is typically taken somewhat conservatively since if you're volunteering to maintain a package, it's your task forever. For example, even though I follow BLIS with great interest, I myself wouldn't want to dive into that yet.

If your goal is to get BLIS into Ubuntu, you're already there: There's a PPA, and everyone is just one command away to add it.

If you want to gain some traction, one way would probably be to demonstrate that you do some things better (faster?) than BLAS, given developers of other software arguments for linking against BLIS rather than BLAS. Perhaps get back to SciPy or NumPy, they'll be able to give you some good feedback.

I think a Debian package should do the same as the openblas one and provide libblas.so.3, to be substitutable at run time (the way the BLIS rpm packaging does). I started doing that along with the rpm spec, but it wasn't clear to me what the actual Debian linear algebra policy is, as I commented somewhere in the issues. Also, I don't like Debian only offering a pthreads version of openblas, not serial or OpenMP, which you probably want for HPC. (I think that was purely for support of numpy for some reason I don't remember, but I don't see why it should exclude the others.)

The specific reason to have BLIS included is the KNL and SKX BLAS support, which OpenBLAS doesn't have.

@loveshack Curious: Why is the soname of the shared library chosen to be 3 (in libblas.so.3)?

Thanks Dave, but I guess my question is why is it a convention that libblas.so.3 use an soname of 3? Is it because BLAS did not change after the introduction of the level-3 operations? I can't help but notice that all of the other netlib libraries seem to use an soname of 3 as well. Maybe it has to do with the current major version number of LAPACK? (It's okay if you don't know the answer.)

@loveshack Okay, sounds like the "3" is just coincidence then.

(A library increasing its soname occasionally is not surprising to me. But my question was motivated by the fact that I was under the impression that netlib BLAS, which is what I think of when I see libblas, simply did not experience the kinds of changes that would break its ABI, since it was unrolled in a way that did not break old functionality, but rather just added new operations. But I can sleep fine not getting to the bottom of this one.)

@loveshack Do you see any issue with simply providing a symbolic link named libblas.so.3? I'm not totally in love with this idea, mostly due to the aliasing of the soname of 3 onto libblis's (current) soname of 0, but I'm nevertheless open to a symlink.

For what purpose? It won't work as a dynamic substitute for the original libblas.so.3 because the ELF soname is wrong.

Okay, I suppose I hadn't thought of that.

Hope there aren't any hard feelings, Dave, and that you understand that I'm just trying to balance our own project's conventions with how far we bend over backwards to accommodate existing BLAS conventions (beyond the BLAS API itself). We appreciate your involvement. Let us know how the Fedora thing goes.

I was trying to avoid you having to! I don't particularly expect it to be in the BLIS distribution, but if it isn't in distributions, it's most useful there, and I'd think most people's interest will be in BLAS for existing applications.

My apologies, I misunderstood. I thought you wanted BLIS to create a libblas.so.3 as part of its standard make install. It sounds like you were instead proposing that this be a feature of the rpm? (If so, we are completely fine with that.)

Are there applications using BLIS directly which could be mentioned?

By using BLIS directly, I take it you mean the "native" (typed- or object-based) BLIS APIs? We're not sure who are users are or what they might be using it for, though it's something we would love to know more about. Unfortunately, github doesn't do a great job of facilitating us to "track" our users or their use cases (perhaps understandably given the premium people place on privacy as of late).

By using BLIS directly, I take it you mean the "native" (typed- or object-based) BLIS APIs?

Yes, that's what I meant.

I wish I could give you an emphatic "yes," but to be honest we just don't know. We hope there will be plenty of applications in the future that make use of the native interfaces.

I'll try to have another look at making the Debian packaging consistent with openblas' if that would be useful.

Feel free to do so (at your own pace). We welcome your contributions.

Sorry for the delay -- been ill.

No worries. Hope you are feeling better.

@nschloe If you have enough time to continue working on BLIS packaging, I can sponsor it for you. This is the initial checklist:

• create packaging repo on salsa.debian.org and push your commits.
• register libblis.so as an candidate of libblas.so.3 via the alternatives system.
• ...

If you have enough time to continue working on BLIS packaging,

That could take a while. If you want quick progress, you just go ahead, take the debian folder from this repo and upload it yourself.

@nschloe I've already got MKL into Debian official repo and I have many other packages to care. So I expect somebody else other than me to finish this package.

@nschloe Hmm..... I've almost finished the package. Please have a look at https://salsa.debian.org/science-team/blis .

@cdluminate Looks good to me.

@loveshack We have created subdirectories for different BLAS implementation so that one could use LD_* to override the default blas/lapack library. I forgot to add such a subdirectory for BLIS though.

~ ❯❯❯ find /usr/lib/x86_64-linux-gnu/ | rg libblas.so.3                                                                                                                                       
/usr/lib/x86_64-linux-gnu/atlas/libblas.so.3
/usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3
/usr/lib/x86_64-linux-gnu/libblas.so.3
/usr/lib/x86_64-linux-gnu/mkl/libblas.so.3                                                                                                                                                    
/usr/lib/x86_64-linux-gnu/openblas/libblas.so.3                                                                                                                                               
/usr/lib/x86_64-linux-gnu/blas/libblas.so.3                                                                                                                                                   
/usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0         

With some additional work producing three versions of libraries is possible, i.e. libblis-serial, libblis-pthread, and libblis-openmp.

I'm not sure what you mean exactly by I'd expect to be able to substitute any BLAS(/LAPACK), but Debian has an alternatives system which could change the default blas/lapack backend for the system.

~ ❯❯❯ sudo update-alternatives --config libblas.so-x86_64-linux-gnu                                                                                                                           
There are 4 choices for the alternative libblas.so-x86_64-linux-gnu (providing /usr/lib/x86_64-linux-gnu/libblas.so).

  Selection    Path                                           Priority   Status                                                                                                               
------------------------------------------------------------                                                                                                                                  
  0            /usr/lib/x86_64-linux-gnu/openblas/libblas.so   40        auto mode                                                                                                            
  1            /usr/lib/x86_64-linux-gnu/blas/libblas.so       10        manual mode                                                                                                          
  2            /usr/lib/x86_64-linux-gnu/libblis.so            37        manual mode                                                                                                          
* 3            /usr/lib/x86_64-linux-gnu/libmkl_rt.so          1         manual mode                                                                                                          
  4            /usr/lib/x86_64-linux-gnu/openblas/libblas.so   40        manual mode                                                                                                          
                                                                                                                                                                                              
Press <enter> to keep the current choice[*], or type selection number: ^C⏎      

@loveshack This page is not a "policy" https://wiki.debian.org/DebianScience/LinearAlgebraLibraries

BLIS is automatically synced into Ubuntu devel branch (current codename: disco) https://launchpad.net/ubuntu/+source/blis

Maybe this issue can be closed now.

@cdluminate Agreed. Thanks for the nudge.