https://bugzilla.suse.com/show_bug.cgi?id=1177260 https://bugzilla.suse.com/show_bug.cgi?id=1177260#c47 Stefan Br�ns <stefan.bruens@rwth-aachen.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(stefan.bruens@rwt | |h-aachen.de) | --- Comment #47 from Stefan Br�ns <stefan.bruens@rwth-aachen.de> --- (In reply to Egbert Eich from comment #46)
(In reply to Stefan Br�ns from comment #45)
I think for Leap/SLE 15, the old SONAME is actually the better option. Otherwise, you need a full rebuild (at least the parts which directly or indirectly use openblas), othwerwise you may end up with a binary which links to openblas.so and openblas_pthreads.so at the same time.
If you don't do a rebuild, you may end up with a user using the openmp openblas.so via update alternatives, and openblas_pthreads.so. I a quite sure this will not work.
Well, the old SONAME scheme would require even more %if ... %endif mess in the spec file. All standard binaries are built for openblas_pthreads.so.0. If we provide a compatibility link, why would a user end up with two openblas libraries? Because of a binary requiring two libs that themselves require openblas - one of which has been rebuilt and one hasn't?
Yes, a dependency on both libraries, directly or indirectly, even over multiple indirections. E.g. everything that embeds a python interpreter, and uses numpy, or scipy. Other examples probably exist. -- You are receiving this mail because: You are on the CC list for the bug.