1 |
Hi all, |
2 |
|
3 |
It occurs to me that my work flow when doing updates follows a fairly |
4 |
predictable (and probably common) pattern. |
5 |
The obvious next step is to wonder why no one though of automating it... |
6 |
|
7 |
When doing updates I tend to look through the package list and classify |
8 |
things based on how likely they are to break. |
9 |
Some packages, like findutils, are pretty robust and generally just get on |
10 |
with working. |
11 |
Other packages, like apache and ssh, need are more fragile and need plenty |
12 |
of configuration. |
13 |
|
14 |
Packages from the second group want emerging on their own, or in small |
15 |
groups, the better to keep an eye out for notices about things that might |
16 |
break, to update configs, and to check that they're running happily. |
17 |
|
18 |
Once the update list is reduced to packages from the first group it's |
19 |
fairly safe to run emerge -u world and not worry about things exploding |
20 |
too badly. |
21 |
|
22 |
|
23 |
So as I say, it occurs to me that most people probably follow some |
24 |
variation of this selective upgrade method. |
25 |
It might be handy to have some kind of metadata in the ebuilds that can be |
26 |
used to indicate a package that is "demanding". |
27 |
Then that flag could be used to highlight the package on a dep tree, or |
28 |
optionally to block the emerge unless the package is specified explicitly. |
29 |
|
30 |
`emerge -vaut @safe` would be kinda useful. |
31 |
|
32 |
Just a thought. |
33 |
|
34 |
Regards, |
35 |
Daniel |