1 |
Neil Bothwick wrote: |
2 |
> On Sun, 12 Feb 2006 14:37:41 +0100, Maarten wrote: |
3 |
> |
4 |
> |
5 |
>>What tickles me the most about the current process is that one sometimes |
6 |
>>gets huge lists of updated files by updating a single package. A package |
7 |
>>which may have never been used, or at least configured, by the user. |
8 |
>>For instance, updating webmin, or snort, yields many many ._cfg files an |
9 |
>>average user knows little about, and does not care about since he never |
10 |
>>tweaked them. In other words, they are in their distibution-default |
11 |
>>state, never edited. It stands to reason everyone would want all those |
12 |
>>files overwritten by the new ones, is it not ? |
13 |
|
14 |
|
15 |
> Not. What is the default settings change. You may not have edited the |
16 |
> config because the old defaults were what you wanted, but the new |
17 |
> defaults may break your system. Your old config file, with the settings |
18 |
> you needed, has now gone to bit heaven and you are left with a broken |
19 |
> system. |
20 |
|
21 |
Hum, I'll go along in that there _may_ be changes in the default |
22 |
behaviour that a user may not want, but tough luck; the opposite is far |
23 |
_more_ likely: that the new binary can't cope with the old config, and |
24 |
you then also are left with a broken system. Same difference... |
25 |
Is is also very possible that the new binary has different behaviour |
26 |
regardless of config. Emerging world can, and does, change things and I |
27 |
would suggest that if a user doesn't want any surprises he/she shouldn't |
28 |
run emerge world in the first place... |
29 |
|
30 |
But apart from that, I'd even dare suggest that, when emerging a package |
31 |
+ its config file changes the default behaviour and that change is not |
32 |
unavoidable (by setting the right options in the new config) that that |
33 |
ebuild is plain broken. There is one exception to that, however: when |
34 |
the change is neccessary from a security standpoint. In that case I'd |
35 |
say it is _good_ that the old config with the insecure setting gets |
36 |
overwritten. Remember, the user _did_not_edit_ the file at any point, so |
37 |
there should be no "expectancy of non-breakage" by an update. |
38 |
If a user explicitly wants to keep the config, what is wrong with him |
39 |
running 'touch' on all configs he wants unchanged? |
40 |
|
41 |
And besides, I never suggested that my new procedure _shouldn't_ make |
42 |
backups of all configs it replaces, just like dispatch-conf can do. |
43 |
|
44 |
In my case, emerge world very often breaks things, no matter if I use |
45 |
the old or the new config. So saying "this may break things" in very |
46 |
rare occasions is a bit like saying "while you're in the air falling |
47 |
down and both your parachutes fail to work, you also get the hiccups". ;-) |
48 |
|
49 |
> Of course, Gentoo is all about choice, so if you want to take that |
50 |
> change, you can set dispatch-conf to do what you want. |
51 |
|
52 |
If you say so... but it is non-obvious. Or if by that you mean I have to |
53 |
make a huge list of CONFIG_PROTECT_MASK files... well, that takes even |
54 |
more time than just running dispatch-conf and be done with it. |
55 |
What I'm looking for is a way to automate things a bit more. Defining a |
56 |
list of what may and what may not be overwritten can be quite tedious, |
57 |
and is by no means automatic. |
58 |
|
59 |
> # Automerge files that the user hasn't modified |
60 |
> # (yes or no) |
61 |
> replace-unmodified=no |
62 |
|
63 |
I _have_ set that setting at "yes" of course, but it works nowhere near |
64 |
useful... even to the point that I figured the setting was broken, or |
65 |
was only a stub for future enhancement... |
66 |
|
67 |
That said, cfg-update sounds exactly like what I need, so... |
68 |
|
69 |
Regards, |
70 |
Maarten |
71 |
-- |
72 |
gentoo-user@g.o mailing list |