On Wed, 17 May 2006 00:30:15 +0200 VMiklos <vmiklos@frugalware.org> wrote:
On Tue, May 16, 2006 at 11:35:18PM +0200, x.chantry@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.