https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c1 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Richard Biener 2014-02-12 09:39:10 UTC --- What openblas expects and how it uses update-alternatives is simply completely broken. To link against openblas install openblas-devel, to link against blas install blas-devel. If openblas-devel were packaged correctly it would conflict with blas-devel with the duplicate file /usr/lib{,64}/libblas.so. So the bug lives entirely within openblas. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c3 --- Comment #3 from Richard Biener 2014-02-12 10:16:44 UTC --- Yes, openblas-devel and blas-devel conflict as they both provide libblas.so. Applications are fine if the actual shared libraries do not conflict (well, if they would then a parallel install wouldn't work at all). I wonder if your users are allowed to change alternatives (which are system wide, so one user breaks the other?)? If they are allowed to change alternatives then they can be allowed to install/remove their desired *blas-devel package as well, no? That said, if you think that the alternatives mechanism is the way to go for providing libblas.so / liblapack.so (which might be so as those are quite "standard" names) then you have to coordinate this and get it done in the "right" way. The correct way is certainly not by alternativ-ing libblas.so.3 but by alternativ-ing libblas.so itself. Which of course needs alternative support from all packages that provide an alternative (not sure how you thought it could work without teaching the blas / lapack packages about the existence of alternatives of it) So, propose sth to opensuse-packaging/factory. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c5 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |lnt-sysadmin@lists.lrz.de, | |scorot@free.fr Resolution|INVALID | --- Comment #5 from Richard Biener 2014-02-12 11:38:38 UTC --- Ok, thanks for the hint. It seems that we inherited that "alternative" from Debian (update-alternatives comes from the dpkg package): # ls -l /etc/alternatives/lib* lrwxrwxrwx 1 root root 27 Dec 11 13:10 /etc/alternatives/libblas.so.3 -> /usr/lib64/libblas.so.3.4.2 lrwxrwxrwx 1 root root 29 Dec 11 13:10 /etc/alternatives/liblapack.so.3 -> /usr/lib64/liblapack.so.3.4.2 It seems somebody added update-alternatives support in this awkward way to lapack Sun Jan 13 00:04:56 UTC 2013 - scorot@free.fr - add update-alternative support to allow user to easily switch between several blas and lapack libraries and then the bug would be that it get's installed as default on update %post -n libblas3 %_sbindir/update-alternatives --install \ %{_libdir}/libblas.so.3 libblas.so.3 %{_libdir}/libblas.so.%{version} 50 /sbin/ldconfig That is, for $1 = 2 (update) the above is wrong? (I'm not familiar with update-alternatives) I still do not approve to the design from Debian. Added CCs for people that created the mess in the first place and reopening for now. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c7 Dmitry Roshchin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry@roshchin.org --- Comment #7 from Dmitry Roshchin 2014-06-17 13:04:53 UTC --- Looks like ldconfig breaks update-ulternatives mechanism, for example: dmitry@main:~/tmp/oct> sudo /usr/sbin/update-alternatives --auto libblas.so.3 update-alternatives: using /usr/lib64/libblas.so.3.4.2 to provide /usr/lib64/libblas.so.3 (libblas.so.3) in auto mode dmitry@main:~/tmp/oct> readlink /usr/lib64/libblas.so.3 /etc/alternatives/libblas.so.3 dmitry@main:~/tmp/oct> sudo /usr/sbin/update-alternatives --config libblas.so.3 There are 4 choices for the alternative libblas.so.3 (providing /usr/lib64/libblas.so.3). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/lib64/libblas.so.3.4.2 50 auto mode 1 /usr/lib64/atlas/libsatlas.so.3 20 manual mode 2 /usr/lib64/atlas/libtatlas.so.3 20 manual mode 3 /usr/lib64/libblas.so.3.4.2 50 manual mode 4 /usr/lib64/libopenblasp.so.0 20 manual mode Press enter to keep the current choice[*], or type selection number: 4 update-alternatives: using /usr/lib64/libopenblasp.so.0 to provide /usr/lib64/libblas.so.3 (libblas.so.3) in manual mode dmitry@main:~/tmp/oct> readlink /usr/lib64/libblas.so.3 /etc/alternatives/libblas.so.3 dmitry@main:~/tmp/oct> sudo /sbin/ldconfig /sbin/ldconfig: /usr/lib64/libopenblasp.so.0 is not a symbolic link dmitry@main:~/tmp/oct> readlink /usr/lib64/libblas.so.3 libblas.so.3.4.2 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c9 --- Comment #9 from Dmitry Roshchin 2014-06-17 13:25:26 UTC --- (In reply to comment #8)

It's rather using alternatives in shared library links which breaks ldconfig. It clearly isn't ldconfigs fault.

But in any case we need solution for switching between BLAS libraries. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c11 --- Comment #11 from Richard Biener 2014-06-17 13:55:58 UTC --- (In reply to comment #10)

(In reply to comment #9)

...

(In reply to comment #8)

...

It's rather using alternatives in shared library links which breaks ldconfig. It clearly isn't ldconfigs fault.

But in any case we need solution for switching between BLAS libraries.

Well, install a different one! (of course they happen to have different SONAME and thus comment#6 doesn't work)

The idea in comment#6 would be workable with stub shared libraries with a common SONAME that dt-need the individual blas libraries. To switch blas implementations simply install the appropriate stub library. Just don't share that SONAME with one of the implementations.

For example using

echo > t.c gcc t.c -o libblasstub.so -Wl,-soname=libblasstub.so -shared -nostdlib -lblas

and then linking against -lblasstub You can then replace libblasstub.so in the system with a different one DT_NEEDing another implementation. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c13 --- Comment #13 from Richard Biener 2014-06-18 07:43:30 UTC --- (In reply to comment #12)

We can use the same solution as Debian:

/usr/lib/libblas.so.3 /usr/lib/liblapack.so.3 /usr/lib/blas/* /usr/lib/lapack/ /usr/lib/atlas/* /usr/lib/openblas/*

there *.so.3 created by update-alternatives.

But which variant is better?

/usr/lib/blas/libblas.so /usr/lib/blas/libblas.so.3 /usr/lib/blas/libblas.so.3.5.0

or

/usr/lib/libblas.so

definitely /usr/lib/libblas.so

/usr/lib/blas/libblas.so.3.5.0

Looks like there is no conflict between -devel packages.

Right, they don't share library names. It's also not necessary to have /usr/lib/atlas/* - only /usr/lib/lapack and /usr/lib/blas are necessary because those create the conflict with the alternatives link.

Using of stub libraries is more difficult, in this case we need to patch applications.

No, you only need to patch blas/lapack implementations. But yes, symlinking is easier - if it works. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c15 --- Comment #15 from Bernhard Wiedemann 2014-06-23 10:00:14 CEST --- This is an autogenerated message for OBS integration: This bug (861081) was mentioned in https://build.opensuse.org/request/show/238325 Factory / lapack -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c17 Matthias Grießmeier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #17 from Matthias Grießmeier 2014-07-02 09:15:51 UTC --- Update released for openSUSE 12.3 and 13.1 - resolved fixed -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.