Comment # 3 on bug 1223783 from Atri Bhattacharya

Many thanks for the feedback.

(In reply to Egbert Eich from comment #2)
> 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.