[pacman-dev] config handling
First, I've to say that I don't see the point of NoUpgrade feature. Default pacman config handling is just great, it'll never overwrite a config file you edited, it'll only upgrade the config files you never edited. Why would anyone not want this ? It just looks like the only sane thing to do. Secondly, since it seems that NoUpgrade makes sense for most people (please tell if I'm not alone finding it pointless :)), there is a very annoying thing with it : it always extract the config file to pacnew, no matter if the current config is the same (you didn't edit it), or the original is the same (you edited it, and want to keep your config file, not reverting to the default config). Thus most of the times, you'll have a pointless pacnew files. It's harder to track when a config file got updated or not. Finally, since I dislike current NoUpgrade behavior, I wanted to remove the config files from there and get the (nice) default pacman config handling, which does just the right thing. But, when a config file is in NoUpgrade, and you (re)install the corresponding package, pacman stores the md5sum of /etc/foo (ie your current local config file), instead of /etc/foo.pacnew (pkg config file). So when you remove a config file from NoUpgrade, and reinstall the package, you are in the case : original=X, current=X, new=Y which is the only case where pacman actually overwrites the config file, which is perfectly right, except that here, the original md5sum is wrong (it's the current config file, instead of the previous pkg one). So you actually lost your custom config file, which pacman should never allow. (I hope you understand that NoUpgrade is the problem causing this, not an answer). I've made a patch that makes NoUpgrade behave less annoyingly (even if I would rather remove it totally), by only extracting a pacnew file when the pkg config file has changed (original = X, new = Y), so no more useless pacnew files. And it fix in the same time the above issue. It always made me feel better with last filesystem upgrade :) (where most of its config files are in NoUpgrade, but the last package update didn't modify these config files, so pacman didn't extract them as .pacnew)
On Tue, May 16, 2006 at 10:09:02PM +0200, x.chantry@wanadoo.fr wrote:
First, I've to say that I don't see the point of NoUpgrade feature.
it was usefull in pacman2 but it's not necessary in pacman3, you're right
I've made a patch that makes NoUpgrade behave less annoyingly
looks good to me, tought of course the final word is Aurelien's or Judd's one ;) ps: please keep the length of your lines under 80 chars, it's a bit annonying udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
On Tue, 16 May 2006 22:40:33 +0200 VMiklos <vmiklos@frugalware.org> wrote:
On Tue, May 16, 2006 at 10:09:02PM +0200, x.chantry@wanadoo.fr wrote:
First, I've to say that I don't see the point of NoUpgrade feature.
it was usefull in pacman2 but it's not necessary in pacman3, you're right
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 :)
I've made a patch that makes NoUpgrade behave less annoyingly
looks good to me, tought of course the final word is Aurelien's or Judd's one ;)
ps: please keep the length of your lines under 80 chars, it's a bit annonying
Sorry about these long lines, I copied them from the current code, but the diff makes them even longer. XC
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 udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
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.
On Tue, May 16, 2006 at 10:09:02PM +0200, x.chantry@wanadoo.fr wrote:
I've made a patch that makes NoUpgrade behave less annoyingly (even if I would rather remove it totally)
ok, as a first step in our tree the NoUpgrade lines are removed udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
participants (2)
-
VMiklos
-
x.chantry＠wanadoo.fr