Le jeudi 30 juillet 2020 à 08:23 +0000, [email protected] a écrit : > On Wed, Jul 29, 2020 at 03:36:12PM +0000, Debian FTP Masters wrote: > > * lib{blas,lapack}.so.3 are again dynamically linked against > > libopenblas.so.0. > > This restores the pre-multi-flavour behaviour. > > Incidentally, this brings back the possibility of checking at runtime > > for > > the presence of openblas_get_config symbol. (Closes: #960728) > > I reviewed the changes, and actually it introduced a regression bug > where the choice of update-alternatives gets rather complicated. > > e.g. if I set libblas.so.3 <--provides-- libopenblas0-serial, and > libopenblas.so.0 <--provides libopenblas0-pthread, then since > openblas-serial/libblas.so.3 NEEDS libopenblas.so.0, and has no > RPATH attribute, ld.so will resolve libblas.so.3's dependency to the > global /usr/lib/<triplet>/libopenblas.so.0, which points to > openblas-pthread/libopenblas.so.0 . This breaks the users assumption > on the "serial" threading of libblas.so.3. > > Severity: important > Fixed in git repo: > https://salsa.debian.org/science-team/openblas/-/commit/5bd3216d3d78c1315627f0e117f2d20c8962eef6
Thanks for spotting and fixing this. Two additional questions (I did not yet try to compile your changes): - I guess that the override_dh_shlibdeps that I added in debian/rules is no longer needed? - Does lintian complain about the rpath? Setting rpath is generally forbidden, but allowed in the case of a private library, so we should be fine: https://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
-- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
