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