Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#71927 - [openblas] split out blas-openblas to provide blas; avoid conflict with blis

Attached to Project: Community Packages
Opened by Jed Brown (jedbrown) - Thursday, 26 August 2021, 15:25 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 31 August 2021, 20:52 GMT
Task Type Feature Request
Category Packages
Status Assigned
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

Description:

BLIS (https://aur.archlinux.org/packages/blis/) provides a BLAS that is smaller and faster than OpenBLAS, but it currently conflicts with `openblas`. Some packages (`julia` in particular) depend directly on `openblas`, so one cannot currently have `blis` and `julia` installed on the same system.

I think the BLAS parts of `openblas` (libblas.so, libblas.so.3, blas.pc) should be split into a new package, `blas-openblas`, which depends on `openblas` and provides `blas`. The same can be done with `blas-blis`, thus allowing `openblas` and `blis` to be installed at the same time, and choose either `blas-openblas` or `blas-blis` as provider of `blas`.

Additional info:
openblas-0.3.17-1
blis-0.8.1-2
This task depends upon

Comment by Marcell Meszaros (MarsSeed) - Wednesday, 23 February 2022, 12:05 GMT
TLDR; openblas package is not at fault, issue is with downstream (consumers of openblas, and/or blas-replacement AUR/blis.)
Suggest closing this task here.

Details:
This request doesn't make sense: libblas.so and libblas.so.3 are just symlinks to the actual libopenblasp-r{version}.so library in this package.

Also, if AUR/blis is a drop-in, API-compatible replacement of BLAS/OpenBLAS, then it should indeed conflict with other BLAS providers.
Only one BLAS-compatible library should be installed at any time providing blas.

@jedbrown I suggest you create separate requests for packages explicitly requiring openblas to require blas instead, or make openblas optional.

Julia, for one, does not itself need openblas. It only creates a symlink in its lib/julia directory to an openblas library:
community/julia/PKGBUILD/package():
ln -s /usr/lib/libopenblas.so "$pkgdir"/usr/lib/julia/libopenblas64_.so # Needed by some 3rd party packages*
(*There are no third-party packages in Arch repository currently that would need Julia's lib/julia/libopenblas64_.so though.)

Another option for you is to ask AUR/blis maintainer to make the package declare it provides and conflicts with openblas,
and create openblas symlinks to its own blas-compatible library inside its package.
Comment by Antonio Rojas (arojas) - Wednesday, 23 February 2022, 13:38 GMT
@MarsSeed You are misunderstanding the request I think. libblas.so and libblas.so.3 are indeed just symlinks to libopenblas, which makes openblas a drop-in replacement for blas. The request is to move the symlinks to a separate package so openblas can be installed for packages that hard-depend on it, while still using another provider for libblas.so.*

As for julia: no, it can not depend on just blas, check the old bug reports for a history of the topic. /usr/lib/julia/libblas.so is symlinked to libopenblas. And "Needed by some 3rd party packages" does not refer to Arch packages, but to Julia packages.
Comment by Jed Brown (jedbrown) - Wednesday, 23 February 2022, 13:57 GMT
Indeed, @arojas' description is correct. Note that BLIS includes interfaces with unique features (e.g., dynamic mixed precision) that some packages may depend on. This request would decouple the choice of default libblas.so from ability to satisfy dependencies for packages that need specific interfaces beyond BLAS (OpenBLAS and BLIS provide BLAS symbols *plus* other interfaces).
Comment by Marcell Meszaros (MarsSeed) - Wednesday, 23 February 2022, 14:44 GMT
Hi @arojas, @jedbrown. Thanks for your input and clarifications.
Sorry for my mistaken assumptions. Your answers have now helped me to understand the rationale behind the request.
Keep up the good work! :)

Loading...