(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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
