| 1 |
On Wednesday 03 January 2007 07:21, Daniel Barkalow wrote: |
| 2 |
> On Tue, 2 Jan 2007, Alan McKinnon wrote: |
| 3 |
> > On Tuesday 02 January 2007 08:50, Daniel Barkalow wrote: |
| 4 |
> > > I also think that emerge should keep track of the config files |
| 5 |
> > > installed by packages, so that etc-update knows if you've got |
| 6 |
> > > local modifications, and give you a big warning when you might |
| 7 |
> > > lose a change you made. |
| 8 |
> > |
| 9 |
> > Huh? Portage already does this. Standard config dirs are |
| 10 |
> > CONFIG_PROTECTed which is where etc-update comes in. It will merge |
| 11 |
> > trivial changes (whitespace, etc) and let *you* chose what to do |
| 12 |
> > for everything else. You get to keep the original file, use the |
| 13 |
> > update, or use a customized merge of the two. |
| 14 |
> |
| 15 |
> The issue is that etc-update doesn't have the version of the config |
| 16 |
> file as installed by the version of the package that's being |
| 17 |
> replaced, so it can't tell the difference between non-trivial changes |
| 18 |
> to the config file as shipped by gentoo between the old version and |
| 19 |
> the new version and non-trivial local modifications that I've made |
| 20 |
> myself to a config file which has not been changed between package |
| 21 |
> versions. I've definitely had etc-update ask for confirmation on |
| 22 |
> files I'm sure I didn't change (including, in some cases, executables |
| 23 |
> that get installed in protected directories). |
| 24 |
|
| 25 |
Neither the computer nor etc-update can think. So why are you asking it |
| 26 |
to think? Because that's what you are asking it to do - make an |
| 27 |
intelligent decision about a config file based on it's contents and how |
| 28 |
it differs from a new version. |
| 29 |
|
| 30 |
The only possible thing etc-update could ever do is look for trivial |
| 31 |
changes and ignore them. How would you detect the difference between |
| 32 |
non-trivial changes to shipped versions and non-trivial changes made |
| 33 |
locally? You can't say that if the config file exists and hasn't |
| 34 |
changed since installation then overwrite it with the new shipped |
| 35 |
version - that might change the behaviour of an *existing* system |
| 36 |
(without notification) if the user likes the old way and does not like |
| 37 |
the new way. |
| 38 |
|
| 39 |
This will cause b.g.o. to be flooded with bugs about how emerge |
| 40 |
obliterated working config files - are you going to be the one to |
| 41 |
answer all those bug reports? |
| 42 |
|
| 43 |
> > There is no need to give you a big warning if you might lose a |
| 44 |
> > change - the very act of running etc-update at all IS that warning. |
| 45 |
> > It's understood that if the new file shows up, then you DO have |
| 46 |
> > local modifications |
| 47 |
> |
| 48 |
> It's understood that there is a difference between what I'm using now |
| 49 |
> and what new package comes with. But there's no information on |
| 50 |
> whether that difference came from local modifications. |
| 51 |
|
| 52 |
And neither should there be. Etc-update knows the files are *different* |
| 53 |
and stops right there. Evaluating what that difference means is a |
| 54 |
human's job because it's not a monkey-see, monkey-do process. |
| 55 |
|
| 56 |
Again: the computer cannot think. Don't expect it to. |
| 57 |
|
| 58 |
alan |
| 59 |
-- |
| 60 |
gentoo-user@g.o mailing list |
Archives