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