Hello, will send this to gentoo-dev mailing list per Zac's suggestion ;):
Probably Zac already remembers my suggestion of: https://bugs.gentoo.org/show_bug.cgi?id=413619 Sorry for insisting a bit on it but this issue bites me periodically. Months ago, I was able to administrate myself some of my father and uncles systems in their jobs and homes but, since I moved to Madrid this year, I am not able to administrate them directly. They usually do a good job maintaining them, the only issue I see they hit from time to time is forgetting to run JUST AFTER updating their systems revdep-rebuild (well, this is so common that they usually don't forget to), rebuild dbus-glib/gobject-introspection after major glib update, rebuild X11 drivers... This is because, even if all this information is recorded in /var/log/portage/elog/summary.log, currently, that log file is cluttered of a lot of other elog lines that are not related at all with this important task of rebuilding packages. This is why I suggested: https://bugs.gentoo.org/show_bug.cgi?id=413619 That would create a new "erebuild" (or whatever the name you prefer) to ONLY contain exact command to run by admin to have a safe system after update. It would have as main advantage: - Looks easier to implement. - It relies in current and existing tools (python-updater, perl-cleaner, "q", equery...), then, they could be used just now via a script running all of them. - It also looks much more "professional" to try to unify a bit what commands to run ;) (currently, some ebuilds tells you to manually re-emerge packages and some people wrongly run "emerge dbus-glib" when they should run "emerge -1 dbus-glib". Telling us to people what exact command they need to copy&paste&run will help to get their systems cleaner also. Zac kindly pointed me to: https://bugs.gentoo.org/show_bug.cgi?id=192319 The problem of that one is that, even if it would be "the perfect solution": - Looks to be stalled for a long time. - Looks to need a lot of functions (like revdep-rebuild, python-updater...) to be merged in portage itself. It will then probably take a lot of time to get them integrated (specially seeing we are still not able to use preserve-libs because it looks to cause some other problems) - In that bug report I have also seen discussion about whether handle this only via SLOTs (that personally think it will be even harder to achieve for all packages in the tree showing this kind of problems when updating, for example, I doubt how "glib" - "dbus-glib/g-i" case could be handled in this way. - Looks like there is no consensus about what to do and, then, this could probably be implemented on eapi... 7? While former could probably be implemented much sooner (probably even in eapi5) This is why I think we should try to push a bit my first suggestion for the short term until "the perfect one" is ready as, until then, we are having for years a problem that, personally, I think it should be handled a bit better. Thanks a lot for your attention
signature.asc
Description: This is a digitally signed message part
