Bugzilla – Bug 1207563
[openblas, lapack] Files for 'update alternatives' conflict with their 32-bit Counterparts
Last modified: 2024-06-14 17:49:48 UTC
lapack and openblas create links in /etc/alternatives to facilitate the installation of both lapack/blas flavors. Since these name of these links correspond to the file names of the link targets, they will conflict between 64-bit versions and 32-bit counterparts. The real libs of course live in separate trees and therefore don't conflict.
Actually, this appears to be more of a non-issue as 32bit compatibility packages seem to be stripped of the update-alternatives. For liblapack: # rpm -q --scripts liblapack3 postinstall scriptlet (using /bin/sh): /usr/sbin/update-alternatives --install \ /usr/lib64/liblapack.so.3 liblapack.so.3_x86_64 /usr/lib64/lapack/liblapack.s /sbin/ldconfig preuninstall scriptlet (using /bin/sh): if [ "$1" = 0 ] ; then /usr/sbin/update-alternatives --remove liblapack.so.3 /usr/lib64/lapack/libla fi postuninstall program: /sbin/ldconfig posttrans scriptlet (using /bin/sh): if [ "$1" = 0 ] ; then if ! [ -f /usr/lib64/liblapack.so.3 ] ; then "/usr/sbin/update-alternatives" --auto liblapack.so.3 fi fi # rpm -q --scripts liblapack3-32bit postinstall scriptlet (using /bin/sh): /sbin/ldconfig For libopenblas: # rpm -q --scripts libopenblas_openmp0 postinstall scriptlet (using /bin/sh): /usr/sbin/update-alternatives --install \ /usr/lib64/openblas-default openblas-default_x86_64 /usr/lib64/openblas-openm for lib in libblas.so.3 libcblas.so.3 liblapack.so.3 liblapacke.so.3; do /usr/sbin/update-alternatives --install \ /usr/lib64/${lib} ${lib}_x86_64 /usr/lib64/libopenblas.so.0 20 done /sbin/ldconfig postuninstall scriptlet (using /bin/sh): if [ ! -f /usr/lib64/openblas-openmp/libopenblas.so.0 ]; then for lib in libblas.so.3 libcblas.so.3 liblapack.so.3 liblapacke.so.3; do /usr/sbin/update-alternatives --remove ${lib} /usr/lib64/libopenblas.so. done fi if [ ! -d /usr/lib64/openblas-openmp ]; then /usr/sbin/update-alternatives --remove openblas-default /usr/lib64/openblas- fi /sbin/ldconfig posttrans scriptlet (using /bin/sh): if [ "$1" = 0 ] ; then if [ ! -d /usr/lib64/openblas-default ] ; then /usr/sbin/update-alternatives --auto openblas-default fi for lib in libblas.so.3 libcblas.so.3 liblapack.so.3 liblapacke.so.3; do if ! [ -f /usr/lib64/${lib} ] ; then /usr/sbin/update-alternatives --auto ${lib} fi done fi # rpm -q --scripts libopenblas_openmp0-32bit postinstall scriptlet (using /bin/sh): /sbin/ldconfig
That only means the post script added to the -32bit is wrong too. check the files in the -32bit package: you get 0-byte files where they are supposed to be symlinks (making the entire-32bit package basically broken anyway) > rpm -qlvp liblapacke3-32bit-3.9.0-5.4.x86_64.rpm drwxr-xr-x 2 root root 0 Aug 31 14:19 /usr/lib/lapack lrwxrwxrwx 1 root root 19 Aug 31 14:19 /usr/lib/lapack/liblapacke.so.3 -> liblapacke.so.3.9.0 -rwxr-xr-x 1 root root 2262368 Aug 31 14:19 /usr/lib/lapack/liblapacke.so.3.9.0 -rw-r--r-- 1 root root 0 Aug 31 14:19 /usr/lib/liblapacke.so.3 /usr/lib/liblapacke.so.3 is supposed to be the symlink (in the normal package it's a %ghost link, in -32bit it's a real file, 0byte)
(In reply to Dominique Leuenberger from comment #2) > That only means the post script added to the -32bit is wrong too. But this is nothing I could fix in the post script template in the spec file, is it? > check the files in the -32bit package: you get 0-byte files where they are > supposed to be symlinks (making the entire-32bit package basically broken > anyway) > Right. I've noticed this as well. It is a different problem, though - but definitely one that would have to be fixed on the baselibs magic. > > > rpm -qlvp liblapacke3-32bit-3.9.0-5.4.x86_64.rpm > drwxr-xr-x 2 root root 0 Aug 31 14:19 > /usr/lib/lapack > lrwxrwxrwx 1 root root 19 Aug 31 14:19 > /usr/lib/lapack/liblapacke.so.3 -> liblapacke.so.3.9.0 > -rwxr-xr-x 1 root root 2262368 Aug 31 14:19 > /usr/lib/lapack/liblapacke.so.3.9.0 > -rw-r--r-- 1 root root 0 Aug 31 14:19 > /usr/lib/liblapacke.so.3 > > /usr/lib/liblapacke.so.3 is supposed to be the symlink (in the normal > package it's a %ghost link, in -32bit it's a real file, 0byte)
(In reply to Egbert Eich from comment #3) > (In reply to Dominique Leuenberger from comment #2) > > That only means the post script added to the -32bit is wrong too. > > But this is nothing I could fix in the post script template in the spec > file, is it? You need to duplicate the u-l logic in the baselibs.conf ocl-icd/baselibs.conf has some magic to not use u-l in -32bit, but that's arguably not the best solution; alternatively, you have to copy the script from the spec to baselibs.conf
Hi Atri, sorry for throwing you right in the middle of this ticket. You have re-added baselibs.conf support to the openblas package a while ago. We discovered that there are some pieces missing. One issue (conflict of links in /etc/alternatives/) has been fixed in science/openblas and science/lapack, however not submitted to Factory, yet. The script part to maintain these links for 32-bit is missing, it would have to be added to baselibs.conf for the packages openblas and lapack. Since the exact semantics may require some fiddling and I don't know of a good way to test the results without building the entire package in OBS, this is beyond the effort I'm willing to invest. Would you be able to look into this?
(In reply to Egbert Eich from comment #5) > Hi Atri, > sorry for throwing you right in the middle of this ticket. No problem, happy to help where I can. > > You have re-added baselibs.conf support to the openblas package a while ago. > > We discovered that there are some pieces missing. One issue (conflict of > links in /etc/alternatives/) has been fixed in science/openblas and > science/lapack, however not submitted to Factory, yet. > The script part to maintain these links for 32-bit is missing, it would have > to be added to baselibs.conf for the packages openblas and lapack. Since the > exact semantics may require some fiddling and I don't know of a good way to > test the results without building the entire package in OBS, this is beyond > the effort I'm willing to invest. > > Would you be able to look into this? I'll take a stab at it tomrrow and see what I can come up with.
(In reply to Atri Bhattacharya from comment #6) > (In reply to Egbert Eich from comment #5) > > Would you be able to look into this? > > I'll take a stab at it tomrrow and see what I can come up with That's great, thanks! Please bear in mind that even with this fixed, not everything will be great immediately as there still is: https://github.com/openSUSE/obs-build/issues/912 which would have to be fixed as well.
SUSE-FU-2023:0789-1: An update that contains one feature and has six feature fixes can now be installed. Category: feature (important) Bug References: 1087426, 1166619, 1184786, 1207358, 1207563, 1207989 Jira References: PED-3628 Sources used: openSUSE Leap 15.4 (src): lapack-3.9.0-150000.4.13.2, lapack-man-3.9.0-150000.4.13.2 Basesystem Module 15-SP4 (src): lapack-3.9.0-150000.4.13.2 Development Tools Module 15-SP4 (src): lapack-3.9.0-150000.4.13.2 SUSE Linux Enterprise High Performance Computing 15 SP1 LTSS 15-SP1 (src): lapack-3.9.0-150000.4.13.2 SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 (src): lapack-3.9.0-150000.4.13.2 SUSE Linux Enterprise High Performance Computing ESPOS 15 SP3 (src): lapack-3.9.0-150000.4.13.2 SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 (src): lapack-3.9.0-150000.4.13.2 SUSE Linux Enterprise Real Time 15 SP3 (src): lapack-3.9.0-150000.4.13.2 SUSE Linux Enterprise Server 15 SP1 LTSS 15-SP1 (src): lapack-3.9.0-150000.4.13.2 SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 (src): lapack-3.9.0-150000.4.13.2 SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 (src): lapack-3.9.0-150000.4.13.2 SUSE Linux Enterprise Server for SAP Applications 15 SP1 (src): lapack-3.9.0-150000.4.13.2 SUSE Linux Enterprise Server for SAP Applications 15 SP2 (src): lapack-3.9.0-150000.4.13.2 SUSE Linux Enterprise Server for SAP Applications 15 SP3 (src): lapack-3.9.0-150000.4.13.2 SUSE Manager Proxy 4.2 (src): lapack-3.9.0-150000.4.13.2 SUSE Manager Retail Branch Server 4.2 (src): lapack-3.9.0-150000.4.13.2 SUSE Manager Server 4.2 (src): lapack-3.9.0-150000.4.13.2 SUSE Enterprise Storage 7.1 (src): lapack-3.9.0-150000.4.13.2 SUSE Enterprise Storage 7 (src): lapack-3.9.0-150000.4.13.2 SUSE CaaS Platform 4.0 (src): lapack-3.9.0-150000.4.13.2 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
I am working on this as part of the lapack upgrade (bug 1223783). Took me some time to learn the ropes, but here is what finally seems to work (for libblas3-32bit for example): > ~> cat baselibs.conf > libblas3 > requires "update-alternatives" > postin "ln -sf /etc/alternatives/libblas.so.3_<targettype> /usr/%_lib/libblas.so.3" > postin "/usr/sbin/update-alternatives --force --install /usr/%_lib/libblas.so.3 libblas.so.3_<targettype> /usr/%_lib/blas/libblas.so.3 50" > postun "/usr/sbin/update-alternatives --remove libblas.so.3_<targettype> /usr/%_lib/blas/libblas.so.3" > ... Sorry for the long delay.
This is an autogenerated message for OBS integration: This bug (1207563) was mentioned in https://build.opensuse.org/request/show/1180788 Factory / lapack
Fixed as part of bug 1223783 <https://build.opensuse.org/request/show/1180788>