since upstream commit in libksysguard git https://github.com/KDE/libksysguard/commit/834de9a585c6509f934e9941a5369fed70e6b2c9 "Introduce ProcessDataModel" emerge does copy shared object files in install phase but does not merge them. Emerge reports no error. This ends in dead links in /usr/lib*/ ls -l /usr/lib64/libksgrd.so* lrwxrwxrwx 1 root root 13 27. Apr 23:40 /usr/lib64/libksgrd.so -> libksgrd.so.9 lrwxrwxrwx 1 root root 19 27. Apr 23:40 /usr/lib64/libksgrd.so.9 -> libksgrd.so.5.18.80 before that commit: joerg@jlgentoo ~ $ ls -l /usr/lib64/libksgrd.so* lrwxrwxrwx 1 root root 13 27. Apr 23:42 /usr/lib64/libksgrd.so -> libksgrd.so.8 -rwxr-xr-x 1 root root 105368 27. Apr 23:42 /usr/lib64/libksgrd.so.5.18.80 lrwxrwxrwx 1 root root 19 27. Apr 23:42 /usr/lib64/libksgrd.so.8 -> libksgrd.so.5.18.80 Could be caused by the so.version change. As I didn't find a fitting upstream bug and this survived in kde git for at least 13 days, I think this could be a Gentoo bug.
(In reply to jospezial from comment #0) > As I didn't find a fitting upstream bug and this survived in kde git for at > least 13 days, I think this could be a Gentoo bug. As I didn't find a fitting upstream bug and this survived in the git for some weeks, I think this could be a Gentoo bug.
No build.log? This is not your first bug report. I think you are seeing preserve-libs in action. Upstream soname changed but something installed depends on old soversion.
Created attachment 635260 [details] build.log
There were no messages about preserved-libs after emerging. This in build.log what I don't know what it means, why it didn't copy the new obj files but deletes the old ones: >>> needed obj /usr/lib64/libksgrd.so.5.18.80 >>> needed sym /usr/lib64/libksgrd.so.8 >>> needed obj /usr/lib64/libksignalplotter.so.5.18.80 >>> needed sym /usr/lib64/libksignalplotter.so.8 >>> needed obj /usr/lib64/libprocesscore.so.5.18.80 >>> needed sym /usr/lib64/libprocesscore.so.8 >>> needed obj /usr/lib64/libprocessui.so.5.18.80 >>> needed sym /usr/lib64/libprocessui.so.8 >>> Safely unmerging already-installed instance... >>> Original instance of package unmerged safely. >>> kde-plasma/libksysguard-9999 merged. >>> Regenerating /etc/ld.so.cache... <<< !needed obj /usr/lib64/libksgrd.so.5.18.80 <<< !needed sym /usr/lib64/libksgrd.so.8 <<< !needed obj /usr/lib64/libksignalplotter.so.5.18.80 <<< !needed sym /usr/lib64/libksignalplotter.so.8 <<< !needed obj /usr/lib64/libprocesscore.so.5.18.80 <<< !needed sym /usr/lib64/libprocesscore.so.8 <<< !needed obj /usr/lib64/libprocessui.so.5.18.80 <<< !needed sym /usr/lib64/libprocessui.so.8 Uninstalled without messages about preserved-libs and a fresh merge worked correctly: ls -l /usr/lib*/libksgrd.so* lrwxrwxrwx 1 root root 13 30. Apr 06:45 /usr/lib64/libksgrd.so -> libksgrd.so.9 -rwxr-xr-x 1 root root 105368 30. Apr 06:45 /usr/lib64/libksgrd.so.5.18.80 lrwxrwxrwx 1 root root 19 30. Apr 06:45 /usr/lib64/libksgrd.so.9 -> libksgrd.so.5.18.80 ls -l /usr/lib64/libprocess* lrwxrwxrwx 1 root root 19 30. Apr 06:45 /usr/lib64/libprocesscore.so -> libprocesscore.so.9 -rwxr-xr-x 1 root root 266640 30. Apr 06:45 /usr/lib64/libprocesscore.so.5.18.80 lrwxrwxrwx 1 root root 25 30. Apr 06:45 /usr/lib64/libprocesscore.so.9 -> libprocesscore.so.5.18.80 lrwxrwxrwx 1 root root 17 30. Apr 06:45 /usr/lib64/libprocessui.so -> libprocessui.so.9 -rwxr-xr-x 1 root root 351584 30. Apr 06:45 /usr/lib64/libprocessui.so.5.18.80 lrwxrwxrwx 1 root root 23 30. Apr 06:45 /usr/lib64/libprocessui.so.9 -> libprocessui.so.5.18.80 Let's see if this will help in future: (not installed) dev-util/kdevelop: Add slot op on kde-plasma/libksysguard kde-plasma/libksysguard: Add subslot Should all packages that depend on libksysguard get a slot op? These packages depend on libksysguard: kde-plasma/ksysguard-9999 (>=kde-plasma/libksysguard-9999:5[-minimal(-)]) kde-plasma/plasma-desktop-9999 (>=kde-plasma/libksysguard-9999:5) kde-plasma/plasma-workspace-9999 (>=kde-plasma/libksysguard-9999:5)
(In reply to jospezial from comment #4) > There were no messages about preserved-libs after emerging. There were likely no messages at the end because the same emerge also updated all relevant kde-plasma/* packages depending on libksysguard, thus there is no need for a slot operator.
I mean, a slot operator on dependencies within kde-plasma/* would only help you with live versions where it is likely a non-issue as seen here. ...and theoretically if someone mixed different major versions of libksysguard and other kde-plasma/*, then once in 5 years the subslot changes, but you're skrewed in different ways already if you mix different major kde-plasma/* packages.
It is happening now with kde-apps/libksane-9999 https://invent.kde.org/graphics/libksane/-/commit/66f2eb156e8ec52ee4787530ea5053eb1d7c5ebb set SOVERSION kde-misc/skanlite-9999 and kde-apps/kolourpaint-9999 fail: CMake Error at /usr/lib64/cmake/KF5Sane/KF5SaneTargets.cmake:88 (message): The imported target "KF5::Sane" references the file "/usr/lib64/libKF5Sane.so.21.03.70" but this file does not exist. ls -l /usr/lib64/libKF5Sane* lrwxrwxrwx 1 root root 15 8. Mär 01:39 /usr/lib64/libKF5Sane.so -> libKF5Sane.so.5 lrwxrwxrwx 1 root root 22 8. Mär 01:39 /usr/lib64/libKF5Sane.so.5 -> libKF5Sane.so.21.03.70 I will test which files will be merged after unmerge kde-misc/skanlite-9999 and kde-apps/kolourpaint-9999.
After unmerging kde-misc/skanlite-9999 and kde-apps/kolourpaint-9999 all files will be merged. ls -l /usr/lib64/libKF5Sane* lrwxrwxrwx 1 root root 15 8. Mär 09:04 /usr/lib64/libKF5Sane.so -> libKF5Sane.so.5 -rwxr-xr-x 1 root root 341168 8. Mär 09:04 /usr/lib64/libKF5Sane.so.21.03.70 lrwxrwxrwx 1 root root 22 8. Mär 09:04 /usr/lib64/libKF5Sane.so.5 -> libKF5Sane.so.21.03.70 This libs preserving is a bit strange and contra productive at this point. More a sys-apps/portage bug. Should I reopen,rename this an then reassigning to the portage people?
It happened because of an unintended soversion change from an upstream build system update, bug 772017. If you ask me, it's a problem a live ebuild user should be able to deal with. But you can certainly raise it with portage proj.
