installcheck misses file conflicts involving soft links

[e4t]

Recently, a conflict was reported by installeck on IBS pull request 287919 which was to update openblas for SLE-15-SP5 to the latest Factory version.
The error message read:

found conflict of liblapacke3-32bit-3.5.0-4.6.1.x86_64 with
libopenblas_openmp0-32bit-0.3.21-150500.1.2.x86_64
  /usr/lib/liblapacke.so.3 [mode mismatch: l777 root:root -> liblapacke.so.3.5.0, g -644 root:root]

found conflict of liblapacke3-32bit-3.5.0-4.6.1.x86_64 with
libopenblas_pthreads0-32bit-0.3.21-150500.1.2.x86_64
  /usr/lib/liblapacke.so.3 [mode mismatch: l777 root:root -> liblapacke.so.3.5.0, g -644 root:root]

found conflict of liblapacke3-32bit-3.5.0-4.6.1.x86_64 with
libopenblas_serial0-32bit-0.3.21-150500.1.2.x86_64
  /usr/lib/liblapacke.so.3 [mode mismatch: l777 root:root -> liblapacke.so.3.5.0, g -644 root:root]

At first it was assumed that this was due to the recent re-introduction of 32-bit compatibility libraries as the error message was only displayed for these (note the -32bit). Further examination however showed, that the 'regular' 64-bit library packages exhibit the same issue. In fact, there exists a conflict between libopenblas_[openmp|pthread|serial]0-0.3.21 and liblapacke3-3.5.0 as liblapacke3 is missing the update-alternatives. In fact this conflict exists in Leap15.4/SLE-15-SP4 and has remained unnoticed when openblas was updated for this service pack.
This has raised the concern that installcheck is missing some potential conflicts - in fact, this issue was only unveiled by the re-introduction of 32bit compatibility libs.
The conflicts here are all related to soft links, so it may be assumed that this particular 'file type' may not be handled correctly by installcheck.

[e4t]

I've created a sample project with the exact versions of the two offending packages under: home:eeich:issue2915 on OBS.

[coolo]

Possibly the 64bit packages conflict on rpm level and as such are whitelisted?

[e4t]

Possibly the 64bit packages conflict on rpm level and as such are whitelisted?

@coolo - I'm not sure who would be able to answer this question. I don't know where this whitelisting would be done and probably do not have access to it either.
It would be good to find out if this is the case and why.
It may have been added to fix conflicts with the update-alternatives of lapack and between different flavors of openblas (serial, pthreads and openmp). I believe I have fixed all those in Factory and once bsc#1207358 has been addressed, they should be fixed for SLE-15-SP5 as well.

[DimStar77]

Manually checked on liblapacke3 with libopenblas_openmp0 (x86_64 packages) (first reported pair)

None of those have any conflicts declared (zypper info --conflicts) and the obsoleted in libopenblas)openmp0 have no relevance for liblapacke3

grabbed binaries (again, x86_64) from OBS and, on the reported file, get:

> rpm -qlvp liblapacke3-3.9.0-5.4.x86_64.rpm
lrwxrwxrwx    1 root     root                       33 Aug 31 14:23 /usr/lib64/liblapacke.so.3 -> /etc/alternatives/liblapacke.so.3

> rpm -qlvp libopenblas_openmp0-0.3.21-2.1.x86_64.rpm
lrwxrwxrwx    1 root     root                       33 Dec 28 11:12 /usr/lib64/liblapacke.so.3 -> /etc/alternatives/liblapacke.so.3

so those two at least look correct and seem not conflicting.

On spec file level we have:
lapack.spec: %ghost %{_libdir}/liblapacke.so.3
openblas.spec: %ghost %{_libdir}/liblapacke.so.3

So at least for the packages in factory, there not being detected a conflict seems fine

the -32bit though seem to be a different story and those packages seem basically just defective: the baselibs processor seems to stumble badly over symlinks:

> rpm -qlvp ::import::i586::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

liblapacke.so.3 is packaged as a 0-bye file (not symlink) and as such the checker is correct to complain about it.

Potentially this has changed with the recent extensions of the baselibs parser (which could explain why we did not see it in Factory staging) or we have to dig deeper to find out why we missed it

[DimStar77]

to add to the problem: the symlink from /usr/lib/liblapacke.so.3 to /etc/alternatives/liblapacke.so.3 would not work, as the alternatives name is not unique between 64bit and 32bit installs; so whichever symlink alternatives would point to, the other architecture would be miserably broken

[e4t]

@DimStar77 - thank you for checking!

liblapacke.so.3 is packaged as a 0-bye file (not symlink) and as such the checker is correct to complain about it.

The reason may be the %ghost statement in the spec file.

Potentially this has changed with the recent extensions of the baselibs parser (which could explain why we did not see it in Factory staging) or we have to dig deeper to find out why we missed it

I was concerned about the 32-bit compatibility packages anyway. But since I found an issue with lapack on SLE-15-SP4/5 (in the 64-bit package), I identified this as the root cause of this message and fixed it.

to add to the problem: the symlink from /usr/lib/liblapacke.so.3 to /etc/alternatives/liblapacke.so.3 would not work, as the alternatives name is not unique between 64bit and 32bit installs; so whichever symlink alternatives would point to, the other architecture would be miserably broken

Hrm, indeed. This would require to change
%{_sbindir}/update-alternatives --install %{_libdir}/liblapacke.so.3 liblapacke.so.3 %{_libdir}/lapack/liblapacke.so.3 50
to something like:
%{_sbindir}/update-alternatives --install %{_libdir}/liblapacke.so.3 %{_lib}-liblapacke.so.3 %{_libdir}/lapack/liblapacke.so.3 50
and sync this with the other occurrences (ln -s ln -s %{_sysconfdir}/alternatives.. %{buildroot}/%{_libdir}/.. and %ghost %{_sysconfdir}/alternatives/...
for both lapack and openblas.
On the other hand, installcheck did not complain about the conflicts between 32-bit and 64-bit versions.

[coolo]

One is in lib and one is lib64. Where do you see a conflict? This looks like an INVALID to me

[e4t]

One is in lib and one is lib64. Where do you see a conflict? This looks like an INVALID to me

In the name of the link in /etc/alternatives/. These would be the same for 32- and 64-bit.

[DimStar77]

One is in lib and one is lib64. Where do you see a conflict? This looks like an INVALID to me

both (would) point to /etc/alternatives/liblapacke.so.3, which in turn points back to either /usr/lib64/lapack/liblapacke.so.3
or /usr/lib/lapack/liblapacke.so.3; this is clearly a packaging issue

But there the problem that the -32bit package actually packaged a 0-byte file instead of a ghosted symlink like in the real build (which is a bug in obs-build / mkbaselibs IMHO)

As for THIS issue here, the main concern is: did that baselibs.conf handling change recently (and thus introduce the bug of not having a ghost/symlink in -32bit -> INVALID) or, if no changes: how did this get past out bot;