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 Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:08 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
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

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:08 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/openblas/issues/4
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! :)
Comment by Felix Yan (felixonmars) - Sunday, 04 June 2023, 20:23 GMT
Implemented in 0.3.23-2. Please let me know if it works as expected.

Loading...