(I am reversing the paragraphs so that the order of the replies makes
sense.)
Dominik 'Rathann' Mierzejewski wrote:
Thinking again, we had this discussion over 3 years ago:
https://pagure.io/packaging-committee/issue/352
and another one starting 2 years ago:
https://pagure.io/packaging-committee/issue/588
which is stalled because Orion doesn't have any time lately.
Please note that what I am proposing here is not the same as my proposal
from 3 years ago that was rejected. While I would not complain if my old
proposal were implemented, I am now suggesting a much simpler approach
(which was already hinted at in the last paragraph of my old proposal):
* drop the inefficient implementations reference (netlib) BLAS/LAPACK and
ATLAS (have OpenBLAS Obsolete them),
* use one-way symlinks or linker scripts to make everything linking or
linked to them pick up OpenBLAS instead. So libblas, liblapack and libsatlas
would just redirect to libopenblas,
* I am not sure about libtatlas, ideally it should redirect to libopenblaso,
but libtatlas uses raw pthread wheres libopenblaso uses OpenMP, this may
make a difference (e.g., it will certainly cause problems if the client
program uses OpenMP itself). If libopenblaso does not work as a drop-in
libtatlas replacement, libopenblas would have to be used instead (and the
programs that really want libopenblaso would have to be rebuilt for it).
On Monday, 14 August 2017 at 02:35, Kevin Kofler wrote:
> Dominik 'Rathann' Mierzejewski wrote:
> Symlinking
> libblas.so.3 → libopenblas.so.0
> liblapack.so.3 → libopenblas.so.0
> is enough to get things linked against BLAS and/or LAPACK to pick up
> OpenBLAS instead. A similar symlinking should work for the -devel
> package. If the symlinks confuse ldconfig or cause some other issues,
> linker scripts can be used instead.
It certainly won't be enough for RPM. There needs to be a libblas.so
pointing to a library with SONAME libblas.so.3, same for lapack.
With the above proposal, if libblas.so symlinks to libopenblas.so.0, the
built RPM will have an AutoRequires on libopenblas.so.0, which is fine
(because that is what we want things to use).
For the runtime symlinks (e.g. libblas.so.3 → libopenblas.so.0), explicit
Provides would be needed so that the dependencies in programs still
depending on the legacy sonames can be resolved.
My old proposal, on the other hand, does not use symlinks to do the
redirection at all, but ld.so.conf.d overrides. So that entirely bypasses
the AutoRequires/AutoProvides system. In that proposal, the "libblas.so
pointing to a library with SONAME libblas.so.3" would come from the
reference (netlib) BLAS's blas-devel package.
Hence, I do not understand your objection.
The old proposal is the way to go if you want to support multiple
BLAS/LAPACK implementations. The new proposal is the way to go if you want
to ship a BLAS/LAPACK that just works.
In any case, the goal ought to be that we centrally pick the BLAS/LAPACK
implementation, either at runtime (old proposal) or at compile time (new
proposal) instead of expecting each and every package using BLAS and/or
LAPACK to be patched to pick up the preferred implementation, which is
clearly not working. (We still have different packages linking to different
implementations.)
This is really the same issue as what I complained about with the libidn2
migration. It just does not scale to expect each and every package to be
patched to change the name of the library to link, when the new library is a
drop-in replacement API/ABI-wise and could just be shipped as a true drop-in
replacement also picking up the old name. Doing the latter is not only much
more efficient for the distribution, but also much less error-prone. Not
only does it avoid inconsistencies (as we are seeing with BLAS/LAPACK) now,
but, e.g., the pointless changes that were required for libidn2 ended up
causing this fun bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1479146
Kevin Kofler