| 1 |
On Wed, 3 Jan 2007, Alan McKinnon wrote: |
| 2 |
|
| 3 |
> The only possible thing etc-update could ever do is look for trivial |
| 4 |
> changes and ignore them. How would you detect the difference between |
| 5 |
> non-trivial changes to shipped versions and non-trivial changes made |
| 6 |
> locally? |
| 7 |
|
| 8 |
Keep a copy of the config files for installed packages somewhere in /var, |
| 9 |
and provide etc-update with "this is the version we shipped that's going |
| 10 |
away" on package removal. Currently, it only keeps the hash of the config |
| 11 |
file that goes with a package, so it can only tell whether there was a |
| 12 |
change in the shipped version, not what that change was. Portage actually |
| 13 |
has enough information to detect that the user has modified a |
| 14 |
CONFIG_PROTECTed file (moveme and destmd5 != cfgfiledict.get[myrealdest]), |
| 15 |
but doesn't test this or communicate it to etc-update. |
| 16 |
|
| 17 |
> You can't say that if the config file exists and hasn't |
| 18 |
> changed since installation then overwrite it with the new shipped |
| 19 |
> version - that might change the behaviour of an *existing* system |
| 20 |
> (without notification) if the user likes the old way and does not like |
| 21 |
> the new way. |
| 22 |
|
| 23 |
I didn't say it shouldn't require interaction to get the new shipped |
| 24 |
version; I said it should require extra confirmation to discard changes |
| 25 |
made locally. It should also be able to offer 3-way merge instead of |
| 26 |
2-way, and automatically retain local changes that don't conflict with |
| 27 |
shipped changes. |
| 28 |
|
| 29 |
> > It's understood that there is a difference between what I'm using now |
| 30 |
> > and what new package comes with. But there's no information on |
| 31 |
> > whether that difference came from local modifications. |
| 32 |
> |
| 33 |
> And neither should there be. Etc-update knows the files are *different* |
| 34 |
> and stops right there. Evaluating what that difference means is a |
| 35 |
> human's job because it's not a monkey-see, monkey-do process. |
| 36 |
|
| 37 |
What the difference means is up to the humans, but there's no reason, |
| 38 |
aside from having carelessly lost information previously, that it doesn't |
| 39 |
know where the change came from; that part isn't up to human |
| 40 |
interpretation, and it's valuable information for humans trying to |
| 41 |
evaluate what the difference means. |
| 42 |
|
| 43 |
-Daniel |
| 44 |
*This .sig left intentionally blank* |
| 45 |
-- |
| 46 |
gentoo-user@g.o mailing list |
Archives