Short version: libksane bumped its so-version 5 -> 21, see commit 103dd194c from Jan 28. So in the current era with most of the tree where it'd be useful now subslotted, revdep-rebuild doesn't find much to rebuild any more. However, it does occasionally still catch the occasional dep that's not subslotted, as it did in this case for me. Note that I run the kde-live-git ebuilds from the overlay, thus the question-marks at the end of the summary line above as the alternative to subslots would be a version/rev-bump on deps and of course that doesn't normally occur with live-git builds. However, in the interest of catching and fixing a potential revdep-bug before it hits normal versions if it is a bug that needs fixed, I'm filing this. It can always be closed NOTABUG. Upstream libkscan recently bumped its so-version from 5 to 21 (commit 103dd194c on January 28). Revdep-rebuild says skanlite and kolourpaint need rebuilt as they're now missing libKF5Sane.so.5 . That's libksane, and checking its ebuild, it doesn't appear to be subslotted, so obviously its revdeps can't depend on a subslot, so revdep-rebuild is left to catch the problem and do the rebuilds. I don't know if it's a one-time so-version bump or not, but the 21 suggests they plan to do it annually so a subslot could be useful if synced-version-locks aren't going to be taking care of it anyway. And... does that mean other kde-family-lib so-version-bumps to 21 are on the way? (kde-apps/libkdegames, currently so-version 7.3.0 according to the filename, comes to mind as another kde-apps candidate, and there are surely others.)
I believe upstream 66f2eb156 "set SOVERSION" fixed it. Obviously that triggered another revdep-rebuild, but it was to the expected so.5 version.
Thanks for keeping me up to date. ;) Btw when you say revdep-rebuild, you do really mean `emerge @preserved-rebuild`, right? The former is not really a thing for many years.
(In reply to Andreas Sturmlechner from comment #2) > Btw when you say revdep-rebuild, you do really mean `emerge > @preserved-rebuild`, right? The former is not really a thing for many years. No, I mean revdep-rebuild, or more precisely revdep-rebuild.sh (the old bash version) due to bug #606558 (which I reported and which remains unfixed) with the python version. Years ago when FEATURES=preserve-libs was first introduced to ~arch, I believe before @preserved-rebuild or at least before it was documented so I didn't know about it, I discovered by experience that revdep-rebuild failed to report libs that weren't after-all missing (yet...) due to preserved-libs. Additionally, I realized the potential security issue with leaving old libs libs hanging around until a fuzzy "sometime in the future" and the potential for nasty-to-debug problems with mixed-libs if both versions ended up in an executable's dependency tree. So I set FEATURES=-preserve-libs so the old libs would be removed and revdep-rebuild would continue to find them missing, and continued running revdep-rebuild, which took its time but worked reasonably reliably, as a cleanup step after the emerge --update --deep @world portion of my update routine. I've continued that way ever-since. Problems? Some gcc dependency update a few months ago broke gcc and thus revdep-rebuild, but a quick emerge --usepkgonly of the old version got gcc working again to rebuild the critical package (and if worse comes to worse I could boot to a backup, but that's happened like once due to an unrelated problem, with another couple times I thought it might come to that but it didn't, in the decade and a half plus I've been running gentoo), after which I could emerge --usepkgonly the new version again and was back in business. Other than not being able to start new kde apps in the middle of the occasional qt version update (and I've learned to start an extra konsole or two and kpat before I do full qt updates), that's been about the extent of any problems.
