https://bugzilla.redhat.com/show_bug.cgi?id=1591910 --- Comment #14 from Dave Love <dave.love@xxxxxxxxxxxxxxxx> --- This is probably worth holding for a while, as someone else is packaging BLIS for Debian, and I've asked if we can try to coordinate, and use a common approach to the extent it's not ruled out by Fedora. (In reply to Orion Poplawski from comment #12) > However, I think there are still issues that need to be fleshed out. I'm happy to have discussions and iron out problems/trades-off, of course, which was one reason for submitting it. > The > main issues with how this is packaged now are: > - Installing packages may bring in (unexpectedly) blis instead of blas > because blis provides libblas.so.3()(64bit) I regarded it as similar to other cases where you can swap implementations according to what's installed, but I'm assuming BLIS is strictly better than reference BLAS (though not OpenBLAS). > - There is no consistent/managed way to switch between implementations Yes. Alternatives would have to be in blas, openblas, and atlas as well (not that I can see any need for atlas). > - How do you select between the serial and different parallel versions of > the libblas libraries? They all appear to have the same soname so any could > be selected which is almost certainly incorrect. LD_LIBRARY_PATH is the idea, as in the R example in the URL I referenced. Perhaps an ld.so.conf for the threaded versions is a mistake, though they get lower priority than serial. > - The 64-bit libblas soname is actually libblas64_.so.3()(64bit) Where do you mean? I see this: $ sudo repoquery --provides blas64 blas64 = 3.4.2-8.el7 blas64(x86-64) = 3.4.2-8.el7 libblas64.so.3()(64bit) $ sudo repoquery --provides blis-serial64 blis-serial64 = 0.3.2-3.el7.centos blis-serial64(x86-64) = 0.3.2-3.el7.centos config(blis-serial64) = 0.3.2-3.el7.centos libblas64.so.3()(64bit) libblis64.so.0()(64bit) > For now I think it would be fine to package without the ld.so.conf.d files > and filtering out the libblas* sonames. Users can create their own > ld.so.conf.d file or set LD_LIBRARY_PATH however they choose (e.g. modules). > But beyond that requires distro wide coordination. OK, but let's wait and see if anything useful comes back from Debian. I can't remember exactly what was raised before, but it didn't look as though there was much chance of reversing the decision not to sort this stuff out in Fedora (and Debian doesn't seem actually have the policy I thought I'd seen as a model). Thanks for the comments. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
