![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c3
--- Comment #3 from Atri Bhattacharya
I had briefly played with this idea when I looked at Lapack last, by I find cmake hard to debug, so I didn't pursue it. I'm fine if you do the conversion and make sure that it works ;)
Yes, the transition to cmake was one reason why I wanted to play it extra safe and test all packages dependent on lapack still build (and if they have %check sections, that they run) fine. And it looks ok so far (big batch of python-* packages to check but so far not issues building any of the packages — that were building against old lapack in science — in home:badshah400:lapack2023). I have also been testing put the update (installing, updating, removing, running tests) locally over the weekend.
Regarding update alternatives: They've given me a lot of grief. OBS staging is extremely picky about links that exist in one alternative but not the other. Unfortunately, you cannot run these tests yourself as there is not 'self-service' staging: you need to submit to Factory first and then let the staging managers check what breaks.
The only reason I went into lapack was to fix issues with update alternatives with respect to the openblas implementation. Presently, things are working and I hope I don't have to touch these pieces ever again (OBS staging is extremely picky about links that exist in one package but not the other).
Yes, I think your update-alternatives fixes were perfect and they are preserved in the updated package without any change (except for using _%{_arch} and dropping the user-defined %{a_x} macro but that can be easily switched back). The thing that I have worked on as part of this is to try and understand the baselibs.conf magic and I think I now have the baselibs.conf file in a state that produces working -32bit builds for x86_64 (have no way to test any other archs myself). I basically replicate your update-alternatives scriptlets in the baselibs.conf file with appropriate changes to the syntax. Tests installing, removing, and upgrading packages involving -32bit dependencies are in progress locally on my machine (so far look good). We will have to similarly fix the baselibs.conf for OpenBLAS too.
Regarding switching to 'liblaternatives': a. AFAIKT, libalternatives uses a binary wrapper (`alts`), thus it is for binaries only, not for libraries (@Adam?) b. In case my assessment in a. was wrong: If we do this change, we'd have to change OpenBLAS as well. Since libalternatives is not in SLE-15, we would have to introduce it there if we were to update OpenBLAS. This would in turn require an update to lapack - and possibly a code stream-`fork` (as we may not be able to introduce all required updates to all supported SLE service packs). Things would become much simpler if we kept the update-alternatives in place for the time being and postpone this change to when we know that no new version of OpenBLAS will be required for SLE-15 any more.
Even if we keep update-alternatives for the time being, for SLE (and Leap) we need to make sure that the way they are set up matches the present setting (names and location of links, which links we ship). This can be ensured by leaving update-alternatives in OpenBLAS untouched during this process and make sure we pass Factory staging.
Yes, I agree using libalternatives is not an option at this (or maybe at all) point for lapack. -- You are receiving this mail because: You are on the CC list for the bug.