Hello, will send this to gentoo-dev mailing list per Zac's suggestion ;):
Probably Zac already remembers my suggestion of:
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:
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
Zac kindly pointed me to:
The problem of that one is that, even if it would be "the perfect
- 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
- 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