Gentoo Archives: gentoo-user

From: Maarten <gentoo@××××××××.org>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Handling of config updates, RFC
Date: Sun, 12 Feb 2006 17:19:05
Message-Id: 43EF6D88.8020200@ultratux.org
In Reply to: Re: [gentoo-user] Handling of config updates, RFC by Neil Bothwick
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