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 |