Hello As preserve-libs feature looks to still be unsafe (I haven't tried it yet, but as it's in hardmasked portage versions and looks to have important problems ... :-( ) and looks like they won't be handled soon, maybe we should try to improve current situation: 1. Some ebuilds ask people to manually run equery or "q" to rebuild packages after updates (like PyQt4, xorg-server...) => We should try to unify all this suggestions in only one instead of using random tools, command lines for every ebuild. 2. preserve_old_lib eutils function. The idea, after unifying all commands in, basically, one way to get packages depending on updated package that need rebuild and preserve_old_lib function, generate a "script" from emerge via a system similar than current "elog" tools. Currently, this kind of information is mixed with all kind of different topics in "elog" messages. I suggest to add a new function (for example "ecommand" or whatever name you want) that ONLY contains commandline to run (equery, revdep-rebuild, rm...) This output would still be recorded in summary.log (like elog, ewarn...), but a new file could be created (for example in /var/log/portage/ecommand.sh) with all required commands concatenated by a "&&" (to let script stop when anything fails). That way people could easily run all needed pending commands much more easily. What do you think? Reproducible: Always
(In reply to comment #0) > 1. Some ebuilds ask people to manually run equery or "q" to rebuild packages > after updates (like PyQt4, xorg-server...) => We should try to unify all > this suggestions in only one instead of using random tools, command lines > for every ebuild. > 2. preserve_old_lib eutils function. Both cases can be handled using an ABI dependency approach, as discussed in bug #192319. In essence, the ebuilds tell the package manager about ABI dependencies and ABI changes, and the package manager uses that information to automatically generate a list of packages to rebuild when necessary. *** This bug has been marked as a duplicate of bug 192319 ***
And, isn't it much more difficult than generating a script to let user run it and get things done until better support is implemented? My idea was to try to get this better handled in short time as looks like bug 192319 is more difficult to implement and will probably need much more time to get it done :/
Bug 192319 really isn't that difficult to do, and having ebuilds generate lists of packages is a really backwards approach.
OK in that case :), I was suggesting this workaround as I thought it was more problematic to get it properly solved
