[pacman-dev] config handling

[x.chantry at wanadoo.fr]

On Wed, 17 May 2006 00:30:15 +0200
VMiklos <vmiklos at frugalware.org> wrote:

> On Tue, May 16, 2006 at 11:35:18PM +0200, x.chantry at wanadoo.fr wrote:
> > Ha no I wasn't even aware of the difference about this in pacman3.
> > I was just referring to the fact that config files edited by the user
> > are never overwritten by pacman, so I thought it wasn't necessary
> > (as soon as config files likely to be edited are in the backup section).
> > It can still be useful in some cases I don't see :)
> 
> 2006-01-22 03:30  judd
> 
>         * lib/libalpm/add.c: changed behaviour with
>           original=X,current=Y,new=Z backup scenario -- install new file as
>           .pacnew and keep old one in place
> 
> it seems that later it was backported to pacman2
> 
> just wanted to mention you that before this change the NoUpgrade option
> was really important
> 

Ha yes indeed, this change was made in the latest 2.9.8 release, and it's indeed
very important. But that's really the way it should have been since the start
(since there are no automerging kind of stuff, which doesn't really matter btw :)).
Now if these pacnew files are only extracted when the default config files were 
actually updated, it'll be easier to track down these changes and update manually
the corresponding config files.
I'm glad that you agree that NoUpgrade is less important now, and I can also see
why it was needed before.
So either NoUpgrade should be removed, or moving config files outside NoUpgrade
should be fixed by storing the correct md5sum. My patch does it, since it makes
pacman handle config files in NoUpgrade like the others, but it also checks
md5sum to see whether the pacnew file needs to be extracted or not. So the only
difference left is in the case :
	original=X,current=X,new=Y
where the config file should be safely updated, but NoUpgrade still prevents it
(but doesn't make much sense to me).

Thanks for your comment.