1 |
> Just a quick note. I agree completely that portage must somehow output |
2 |
> this information after a massive emerge, or store it somewhere, however, |
3 |
> I question the sanity of yet another small utility. We already have |
4 |
> etc-update, env-update, modules-update and a host of other 'small' |
5 |
> applications. In my experience helping people on #gentoo, one of the |
6 |
> most common problems is the average new gentoo user's lack of awareness |
7 |
> of the existence of these small helper applications. |
8 |
|
9 |
I can't speak for anyone else, but I didn't mean to suggest an update |
10 |
utility, and I didn't read anyone else's posts to mean that, either. I |
11 |
can see how that would be a logical next step from what was said, but I |
12 |
had rather the idea that Balaji was envisioning something more like a |
13 |
log, which the user could check manually if he or she felt like it. |
14 |
|
15 |
Now that you mention it, Gentoo tends to deal with such logs by way of |
16 |
update applications, but in my mind the most that's needed would be a |
17 |
file listing the "run ebuild config" sorts of messages generated by an |
18 |
emerge. The next time an emerge was run, this file would be replaced. |
19 |
|
20 |
> Integrating this with etc-update or another -update application seems |
21 |
> like a far better idea than just writing another script. |
22 |
|
23 |
> In fact, the idea of replacing all of said applications with ONE |
24 |
> gentoo-update seems like something that should be approached in the near |
25 |
> future. Even if gentoo-update is just a shell script that calls other |
26 |
> shell scripts. |
27 |
|
28 |
I completely agree. I'd love to see that. |
29 |
|
30 |
- John |
31 |
|
32 |
-- |
33 |
|
34 |
Love justice; desire mercy. |
35 |
|
36 |
|
37 |
-- |
38 |
gentoo-dev@g.o mailing list |