1 |
On Wednesday 03 January 2007 20:24, Daniel Barkalow wrote: |
2 |
> On Wed, 3 Jan 2007, Alan McKinnon wrote: |
3 |
> > The only possible thing etc-update could ever do is look for |
4 |
> > trivial changes and ignore them. How would you detect the |
5 |
> > difference between non-trivial changes to shipped versions and |
6 |
> > non-trivial changes made locally? |
7 |
> |
8 |
> Keep a copy of the config files for installed packages somewhere in |
9 |
> /var, and provide etc-update with "this is the version we shipped |
10 |
> that's going away" on package removal. Currently, it only keeps the |
11 |
> hash of the config file that goes with a package, so it can only tell |
12 |
> whether there was a change in the shipped version, not what that |
13 |
> change was. Portage actually has enough information to detect that |
14 |
> the user has modified a CONFIG_PROTECTed file (moveme and destmd5 != |
15 |
> cfgfiledict.get[myrealdest]), but doesn't test this or communicate it |
16 |
> to etc-update. |
17 |
|
18 |
That doesn't work in real life. The system can detect if files have |
19 |
changed, where they changed, when they changed and even who changed |
20 |
them. It does not know, and never will know, *why* the change happened |
21 |
and what the intention of the user was in making the change. Even if a |
22 |
config file has not been changed and a new different version exists, |
23 |
the system has no way to determine whether the existing unchanged |
24 |
version exactly meets my needs or not and whether an automatic update |
25 |
will cause me (the admin) to flip my lid and flame the dev as a result |
26 |
(or not). The machine does not know, the code does not know and the dev |
27 |
does not know. Only *I* know and *I* am the only person that can make |
28 |
this decision. |
29 |
|
30 |
Unix users tend to use it because (amongst other things) the system does |
31 |
not try and second guess us and pull a "we know better than you" stunt. |
32 |
If I want that behaviour, I'll migrate to Windows thank you very much. |
33 |
|
34 |
I know etc-update is a pain in the ass, especially after emerge -uND |
35 |
world and I have to make decisions on 100 CONFIG_PROTECTed files. But |
36 |
even so it's miles better than the alternative. |
37 |
|
38 |
> > You can't say that if the config file exists and hasn't |
39 |
> > changed since installation then overwrite it with the new shipped |
40 |
> > version - that might change the behaviour of an *existing* system |
41 |
> > (without notification) if the user likes the old way and does not |
42 |
> > like the new way. |
43 |
> |
44 |
> I didn't say it shouldn't require interaction to get the new shipped |
45 |
> version; I said it should require extra confirmation to discard |
46 |
> changes made locally. It should also be able to offer 3-way merge |
47 |
> instead of 2-way, and automatically retain local changes that don't |
48 |
> conflict with shipped changes. |
49 |
|
50 |
Please define exactly what a "change that doesn't conflict with shipped |
51 |
changes" means so that I can design a correct algorithm and implement |
52 |
it in C or Python. Include deprecated options, syntax changes, subtle |
53 |
changes in meaning, redefined syntax commands and new conflicting |
54 |
options in config files with the same name across version changes. make |
55 |
it bullet proof so that any regular dev can list these things easily in |
56 |
confidence of their correctness, where the user will know the impact |
57 |
without resorting to looking it up every time, and where the correct |
58 |
thing (defined by whatever $ARB_USER happens to believe they want) is |
59 |
done in the vast overwhelming majority of cases. |
60 |
|
61 |
I'm not jerking your chain here - that is the real spec of a system like |
62 |
you propose. I'm not being pedantic and nit-picking - these are the |
63 |
kind of detail things that make or break software. Windows Update fails |
64 |
in the real world as Microsoft implements vast sweeping monolithic |
65 |
changes leaving the user with no meaningful way to control the process |
66 |
other than "do not apply SPx". Lets not even put one toe onto that |
67 |
road... |
68 |
|
69 |
The various update tools do the only realistic thing possible - the user |
70 |
said to not touch these files, so it doesn't. Period. |
71 |
|
72 |
> > > It's understood that there is a difference between what I'm using |
73 |
> > > now and what new package comes with. But there's no information |
74 |
> > > on whether that difference came from local modifications. |
75 |
> > |
76 |
> > And neither should there be. Etc-update knows the files are |
77 |
> > *different* and stops right there. Evaluating what that difference |
78 |
> > means is a human's job because it's not a monkey-see, monkey-do |
79 |
> > process. |
80 |
> |
81 |
> What the difference means is up to the humans, but there's no reason, |
82 |
> aside from having carelessly lost information previously, that it |
83 |
> doesn't know where the change came from; that part isn't up to human |
84 |
> interpretation, and it's valuable information for humans trying to |
85 |
> evaluate what the difference means. |
86 |
|
87 |
Now you are changing the goal posts. Previously you said the tools |
88 |
should be doing automated changes. Now you say the tools should |
89 |
highlight (as a diff perhaps) what the changes are. Which is it? |
90 |
|
91 |
alan |
92 |
-- |
93 |
gentoo-user@g.o mailing list |