ever so *often* some lib eg. jpeg, x264,... gets updated and a lot of packages need to recompile. however if there is no api change in the lib re-linking would be enough. or to be clear a fast and great solution. so i suggest that this gets integrated into the ebuild system somehow. maybe as a first step with a separate re-link program. and then during revdep-rebuild. (like lafilefixer was a separate program and emerge covers it now during install) this is a suggestion/feature request that would make life way easier. a libjpeg update is a horror on a running GUI system... Reproducible: Always Steps to Reproduce: N/A Actual Results: N/A Expected Results: N/A
If there's no API change there's no change in the .so name expected. If the .so name changes then the API is expected to be different. I don't see how that's supposed to work.
you are "officially right" but: there are bugfix revsion .so name changes ... esp. with libjpeg last year. (i just put in links to keep the GUI/KDE up until i could recompile the whole system) - and also libx264 constantly. it's maybe not an out of the box thing, but e.g. if the ebuild owner of libjpeg knows it's not an API change s/he could add a flag in the ebuild file? something like that?
in that case he probably better fixes the soname, or forward all cursing to upstream
right - i'm not cursing tho ;) the thing is. rebuilding 1/2 the kde for a jpeg bugfix is in the end a gentoo user experience issue.
don't get me wrong, the complaint is completely fair, but I believe there is a limit to what Gentoo should try to fix if upstream is stupid (or maybe the ABI did change, but not for a function that happens to be used a lot (or at all by e.g. KDE))
i did not get you wrong - but upstream will always be stupid somehow ;) it's more the user experience here. so an flag in the ebuild like "BUGFIX_JUST_RELINK" which is ignored by emerge, but taken account of in revdep-rebuild might just do the trick. and you are right - this should NOT be used often. but with care and basic libraries a lot of progs link too... about the ABI or API changes: the ebuild maintainer should know and set the flag if it's clearly a bugfix. on a totally other note, maybe such libs should be slot installed by default, so nothing breaks and the next emerge will use the new lib. but with bugfixes this is not what we want in the end...
I don't understand how you would "just relink". I could imagine the only thing necessary is a symlink from the old soname to the current version of the lib.
sorry for being unclear - yes - that's what i meant and revdep-rebuild should do, with a message to notify the user.
In that case you might want to check out portage 2.2's preserve-libs feature, which at least prevents your system from breaking (as it keeps the old lib around) but eventually does require a rebuild of KDE (and all other consumers). You could theoretically delay this until the next KDE update, though.
if the SONAME changes and it shouldnt, then it's a bug to report to the respective upstream package maintainer, and have it fixed in the specific ebuild. there's no sane way this can be checked automatically by a PM.
