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