1 |
Daniel Bradshaw wrote: |
2 |
> Hi all, |
3 |
> |
4 |
> It occurs to me that my work flow when doing updates follows a fairly |
5 |
> predictable (and probably common) pattern. |
6 |
> The obvious next step is to wonder why no one though of automating it... |
7 |
> |
8 |
> When doing updates I tend to look through the package list and classify |
9 |
> things based on how likely they are to break. |
10 |
> Some packages, like findutils, are pretty robust and generally just get on |
11 |
> with working. |
12 |
> Other packages, like apache and ssh, need are more fragile and need plenty |
13 |
> of configuration. |
14 |
> |
15 |
> Packages from the second group want emerging on their own, or in small |
16 |
> groups, the better to keep an eye out for notices about things that might |
17 |
> break, to update configs, and to check that they're running happily. |
18 |
> |
19 |
> Once the update list is reduced to packages from the first group it's |
20 |
> fairly safe to run emerge -u world and not worry about things exploding |
21 |
> too badly. |
22 |
> |
23 |
> |
24 |
> So as I say, it occurs to me that most people probably follow some |
25 |
> variation of this selective upgrade method. |
26 |
> It might be handy to have some kind of metadata in the ebuilds that can be |
27 |
> used to indicate a package that is "demanding". |
28 |
> Then that flag could be used to highlight the package on a dep tree, or |
29 |
> optionally to block the emerge unless the package is specified explicitly. |
30 |
> |
31 |
> `emerge -vaut @safe` would be kinda useful. |
32 |
> |
33 |
> Just a thought. |
34 |
> |
35 |
> Regards, |
36 |
> Daniel |
37 |
> |
38 |
|
39 |
I am seeing a trend here because this email aligns with the thoughts on |
40 |
the openrc email thread a few days ago. That being said, no clue how to |
41 |
implement it. Actually I think that marking a package as "demanding" |
42 |
would be the more useful than "safe" because probably 95+% of packages |
43 |
are "safe" |
44 |
|
45 |
But, as with a request for an indicator for compile times[1], I think |
46 |
this proposal would be a failure in general because of subjective |
47 |
opinions between people. I would consider apache/lighttpd as being |
48 |
"safe" after initial configuration as long as you don't automatically |
49 |
etc-update. But you or someone else would not think it was safe. |
50 |
Therefore, nice in theory but probably wouldn't work in practice. |
51 |
|
52 |
Nice idea, keep them rolling and I'm not trying to kill the thread. :) |
53 |
|
54 |
-Jeremy |
55 |
[1]: http://bugs.gentoo.org/288193 |