Bugzilla – Bug 1215305
packaging bug: libArcus3 ships lib files with wrong versions
Last modified: 2023-09-30 05:13:10 UTC
libArcus3 ships these files: > rpm -ql libArcus3 /usr/lib64/libArcus.so.1.1.0 /usr/lib64/libArcus.so.3 /usr/share/doc/packages/libArcus3 /usr/share/doc/packages/libArcus3/README.md /usr/share/licenses/libArcus3 /usr/share/licenses/libArcus3/LICENSE > readelf -a /usr/lib64/libArcus.so.1.1.0 | grep SONAME 0x000000000000000e (SONAME) Library soname: [libArcus.so.3] very obviously, that file name seems most invalid for the content it has. Additionally, it causes a file conflict with the to be introduced > readelf -a /usr/lib64/libArcus.so.1.1.0 | grep SONAME 0x000000000000000e (SONAME) Library soname: [libArcus.so.3]
This is an autogenerated message for OBS integration: This bug (1215305) was mentioned in https://build.opensuse.org/request/show/1110915 Factory / libArcus
Several libraries ship a library symlink with a version suffix where the soversion suffix is not a prefix of the version suffix. rpm -ql libksysguard5 libqt5keychain1 libopenjp2-7 libvncserver1 libaccounts-glib0 libappstream4 | grep lib.*\\.so\\..* /usr/lib64/libKSysGuardFormatter.so.1 /usr/lib64/libKSysGuardFormatter.so.5.27.7 /usr/lib64/libKSysGuardSensorFaces.so.1 /usr/lib64/libKSysGuardSensorFaces.so.5.27.7 /usr/lib64/libKSysGuardSensors.so.1 /usr/lib64/libKSysGuardSensors.so.5.27.7 /usr/lib64/libksgrd.so.5.27.7 /usr/lib64/libksgrd.so.9 /usr/lib64/libksignalplotter.so.5.27.7 /usr/lib64/libksignalplotter.so.9 /usr/lib64/liblsofui.so.5.27.7 /usr/lib64/liblsofui.so.9 /usr/lib64/libprocesscore.so.5.27.7 /usr/lib64/libprocesscore.so.9 /usr/lib64/libprocessui.so.5.27.7 /usr/lib64/libprocessui.so.9 /usr/lib64/libqt5keychain.so.0.14.1 /usr/lib64/libqt5keychain.so.1 /usr/lib64/libopenjp2.so.2.5.0 /usr/lib64/libopenjp2.so.7 /usr/lib64/libvncserver.so.0.9.14 /usr/lib64/libvncserver.so.1 /usr/lib64/libaccounts-glib.so.0 /usr/lib64/libaccounts-glib.so.1.25 /usr/lib64/libappstream.so.0.16.3 /usr/lib64/libappstream.so.4
For the general case, this additional symlink causes no problems, as the unique version -> soversion mapping guarantees even multiple versions of the library package (as by the SLPP) will never have any file conflicts. It could only conflict if the "version" symlink of one package clashes with the soversion of another version. But this is totally unlikely, and thus not relevant. The problem is actually caused by the fact the libArcus-lulzbot library is an incompatible fork of libArcus, but kept the library name. The proper fix would be to rename the library of libArcus-lulzbot.
IMHO, this should be RESOLVED INVALID.
As said, INVALID.
It's a violation of the SLPP - packages are named after the versioned files shipped therein. Any .so.1 does not belong in any package called libFOO3 finding another package that violates the policy as a proof to call the bng invalid is useless - it only points out another bug (sort-of libksysguard does not follow slpp anyway)
(In reply to Dominique Leuenberger from comment #6) > It's a violation of the SLPP - packages are named after the versioned files > shipped therein. Yes, but the reverse does *not* hold. > Any .so.1 does not belong in any package called libFOO3 Is is not named .so.1, but .so.1.1.0. > finding another package that violates the policy as a proof to call the bng > invalid is useless - it only points out another bug (sort-of libksysguard > does not follow slpp anyway) So, we will mangle all "violating" upstream packages, just so it matches our expectations, although it is totally unnecessary? Please read my earlier comment again, having one library file named after the SONAME, and a symlink to it using the version is *not* a problem. The problem is caused by the bad libArcus fork. If you disagree, please provide a quote of the relevant SLPP part.
(In reply to Dominique Leuenberger from comment #6) > It's a violation of the SLPP - packages are named after the versioned files > shipped therein. And actually, this statement is incorrect, packages are named after the mangled SONAME. And even packages only containing just a single shared library almost always contain a symlink with the version as suffix. And this symlink does not violate the SLPP - if the used version is based on the version in the SONAME does not matter, even if it often the case.
No violation of the SLPP, as stated.