| Summary: | [kde-overlay] kde-plasma/libksysguard-9999 does copy shared object files in install phase but does not merge them | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | jospezial <jospezial> |
| Component: | Overlays | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build.log | ||
|
Description
jospezial
2020-04-27 22:33:38 UTC
(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. |
