Re: [gentoo-user] Re: anti-portage wreckage?

[Alan McKinnon <alan@linuxholdings.co.za>]

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