[pacman-dev] config handling
* 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).
Hi! I'm new to this list, so please sorry if I do some stupid things. :) Just want to say: NoUpgrade should not be removed! It is very important if, for example I have modified rc.sysinit and don't want it to be silently overwritten during upgrade. For config files (files that are in backup=() array) NoUpgrade is not needed, but it is useful for other files that were modified by user.
On Fri, May 26, 2006 at 12:12:02PM +0300, ????? ??????? <roman.kyrylych@gmail.com> wrote:
Hi! I'm new to this list, so please sorry if I do some stupid things. :) Just want to say: NoUpgrade should not be removed! It is very important if, for example I have modified rc.sysinit and don't want it to be silently overwritten during upgrade. For config files (files that are in backup=() array) NoUpgrade is not needed, but it is useful for other files that were modified by user.
yes, but from the default pacman.conf the noupgrade lines like /etc/fstab can be removed udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
Just want to say: NoUpgrade should not be removed! It is very important if, for example I have modified rc.sysinit and don't want it to be silently overwritten during upgrade. For config files (files that are in backup=() array) NoUpgrade is not needed, but it is useful for other files that were modified by user.
yes, but from the default pacman.conf the noupgrade lines like /etc/fstab can be removed
Not "can" but "should"! :) They are not needed there anymore. I removed all NoUpgrade entries after upgrade to pacman 2.9.8 and had no problems, except with resolv.conf during latest upgrade to filesystem-0.7.2-1 (see http://bugs.archlinux.org/task/4665).
On Fri, May 26, 2006 at 12:12:02PM +0300, ????? ??????? wrote:
* 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).
Hi! I'm new to this list, so please sorry if I do some stupid things. :) Just want to say: NoUpgrade should not be removed! It is very important if, for example I have modified rc.sysinit and don't want it to be silently overwritten during upgrade. For config files (files that are in backup=() array) NoUpgrade is not needed, but it is useful for other files that were modified by user.
Well I thought about this problem, but the way I see it, these files (like rc.sysinit) should be added to the backup array.
On Fri, May 26, 2006 at 01:10:30PM +0300, ????? ??????? wrote:
Just want to say: NoUpgrade should not be removed! It is very important if, for example I have modified rc.sysinit and don't want it to be silently overwritten during upgrade. For config files (files that are in backup=() array) NoUpgrade is not needed, but it is useful for other files that were modified by user.
yes, but from the default pacman.conf the noupgrade lines like /etc/fstab can be removed
Not "can" but "should"! :) They are not needed there anymore. I removed all NoUpgrade entries after upgrade to pacman 2.9.8 and had no problems, except with resolv.conf during latest upgrade to filesystem-0.7.2-1 (see http://bugs.archlinux.org/task/4665).
Well, I tried to explain this problem in my first post.
On Fri, May 26, 2006 at 05:48:15PM +0200, Xavier Chantry wrote:
On Fri, May 26, 2006 at 12:12:02PM +0300, ????? ??????? wrote:
* 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).
Hi! I'm new to this list, so please sorry if I do some stupid things. :) Just want to say: NoUpgrade should not be removed! It is very important if, for example I have modified rc.sysinit and don't want it to be silently overwritten during upgrade. For config files (files that are in backup=() array) NoUpgrade is not needed, but it is useful for other files that were modified by user.
Well I thought about this problem, but the way I see it, these files (like rc.sysinit) should be added to the backup array.
What if I modify something like a variable in an app's script? Let's just say /usr/bin/foobar. /usr/bin/foobar probably shouldn't be in the backup array. The NoUpgrade option lets me make choices about my files regardless of what the packages think. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
rc.sysinit? Well, I thought that only config files should be added to backup array. System shell scripts should not. It is better to use NoUpgrade for them. You cannot add all system shell scripts to backup array, but any of them can be modified by user. User modifies such files in rare situations, so placing all of them in backup array is bad idea; placing only some of them produces problem - how to decide which to place in backup array and which don't? So, IMO it is better to leave things as they are now - use backup array for all config files + XYZ logic, and use NoUpgrade if user modifies some system shell scripts. 2006/5/26, Xavier Chantry <x.chantry@wanadoo.fr>:
On Fri, May 26, 2006 at 12:12:02PM +0300, ????? ??????? wrote:
* 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).
Hi! I'm new to this list, so please sorry if I do some stupid things. :) Just want to say: NoUpgrade should not be removed! It is very important if, for example I have modified rc.sysinit and don't want it to be silently overwritten during upgrade. For config files (files that are in backup=() array) NoUpgrade is not needed, but it is useful for other files that were modified by user.
Well I thought about this problem, but the way I see it, these files (like rc.sysinit) should be added to the backup array.
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Absolutely correct! 2006/5/26, Jason Chu <jason@archlinux.org>:
On Fri, May 26, 2006 at 05:48:15PM +0200, Xavier Chantry wrote:
On Fri, May 26, 2006 at 12:12:02PM +0300, ????? ??????? wrote:
* 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).
Hi! I'm new to this list, so please sorry if I do some stupid things. :) Just want to say: NoUpgrade should not be removed! It is very important if, for example I have modified rc.sysinit and don't want it to be silently overwritten during upgrade. For config files (files that are in backup=() array) NoUpgrade is not needed, but it is useful for other files that were modified by user.
Well I thought about this problem, but the way I see it, these files (like rc.sysinit) should be added to the backup array.
What if I modify something like a variable in an app's script? Let's just say /usr/bin/foobar. /usr/bin/foobar probably shouldn't be in the backup array. The NoUpgrade option lets me make choices about my files regardless of what the packages think.
Jason
-- If you understand, things are just as they are. If you do not understand, things are just as they are.
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
On Fri, May 26, 2006 at 07:01:29PM +0300, ????? ??????? wrote:
rc.sysinit? Well, I thought that only config files should be added to backup array. System shell scripts should not. It is better to use NoUpgrade for them. You cannot add all system shell scripts to backup array, but any of them can be modified by user. User modifies such files in rare situations, so placing all of them in backup array is bad idea; placing only some of them produces problem - how to decide which to place in backup array and which don't? So, IMO it is better to leave things as they are now - use backup array for all config files + XYZ logic, and use NoUpgrade if user modifies some system shell scripts.
Ok I see your point. So should pacman ignore config files in NoUpgrade? or disallow them? or should these files be handled specifically (that's what my patch does) ? Something will have to change in order to fix the problem you reported. Btw, what happen if you remove the package containing the script you edited? For config files, it should save them as .pacsave by default (unless you use the --nosave option). But I guess your edited scripts will be removed. Is this fine? (actually, I didn't even try, so I'm not 100% sure about this behavior) The whole backup stuff is about avoiding to lose custom changes.
When file is in NoUpgrade list Pacman should do it's XYZ logic with one important change - it should NEVER overwrite any file listed in NoUpgrade. By default there should be NO NoUpgrade list in pacman.conf. There is no point to include any _config_ file in NoUpgrade, _only modified system shell scripts_ should be included there (for some rare cases when user modifies them). When package that owns file listed in NoUpgrade is removed - this file should be saved as .pacsave. 2006/5/26, Xavier Chantry <x.chantry@wanadoo.fr>:
On Fri, May 26, 2006 at 07:01:29PM +0300, ????? ??????? wrote:
rc.sysinit? Well, I thought that only config files should be added to backup array. System shell scripts should not. It is better to use NoUpgrade for them. You cannot add all system shell scripts to backup array, but any of them can be modified by user. User modifies such files in rare situations, so placing all of them in backup array is bad idea; placing only some of them produces problem - how to decide which to place in backup array and which don't? So, IMO it is better to leave things as they are now - use backup array for all config files + XYZ logic, and use NoUpgrade if user modifies some system shell scripts.
Ok I see your point. So should pacman ignore config files in NoUpgrade? or disallow them? or should these files be handled specifically (that's what my patch does) ? Something will have to change in order to fix the problem you reported.
Btw, what happen if you remove the package containing the script you edited? For config files, it should save them as .pacsave by default (unless you use the --nosave option). But I guess your edited scripts will be removed. Is this fine? (actually, I didn't even try, so I'm not 100% sure about this behavior)
The whole backup stuff is about avoiding to lose custom changes.
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
On Sat, May 27, 2006 at 12:40:02AM +0300, ????? ??????? wrote:
When file is in NoUpgrade list Pacman should do it's XYZ logic with one important change - it should NEVER overwrite any file listed in NoUpgrade.
That's what I did.
By default there should be NO NoUpgrade list in pacman.conf. There is no point to include any _config_ file in NoUpgrade, _only modified system shell scripts_ should be included there (for some rare cases when user modifies them).
I agree.
When package that owns file listed in NoUpgrade is removed - this file should be saved as .pacsave.
Yep, but I was asking about the current pacman behavior, since I couldn't try it. Having a second look at the code, it finally seems it's already what happens, so it's fine.
Current behaviour seems fine to me too. All I said is just for clarification of how it should be so no changes in this behaviour should be made (e.g. NoUpgrade functionality should not be removed, and other files (not config files) shouldn't be added to backup array). 2006/5/27, Xavier Chantry <x.chantry@wanadoo.fr>:
On Sat, May 27, 2006 at 12:40:02AM +0300, ????? ??????? wrote:
When file is in NoUpgrade list Pacman should do it's XYZ logic with one important change - it should NEVER overwrite any file listed in NoUpgrade.
That's what I did.
By default there should be NO NoUpgrade list in pacman.conf. There is no point to include any _config_ file in NoUpgrade, _only modified system shell scripts_ should be included there (for some rare cases when user modifies them).
I agree.
When package that owns file listed in NoUpgrade is removed - this file should be saved as .pacsave.
Yep, but I was asking about the current pacman behavior, since I couldn't try it. Having a second look at the code, it finally seems it's already what happens, so it's fine.
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
I just found your first post. How could I miss it? Thank you for patch. It does exactly what I meant. 2006/5/27, Роман Кирилич <roman.kyrylych@gmail.com>:
Current behaviour seems fine to me too. All I said is just for clarification of how it should be so no changes in this behaviour should be made (e.g. NoUpgrade functionality should not be removed, and other files (not config files) shouldn't be added to backup array).
2006/5/27, Xavier Chantry <x.chantry@wanadoo.fr>:
On Sat, May 27, 2006 at 12:40:02AM +0300, ????? ??????? wrote:
When file is in NoUpgrade list Pacman should do it's XYZ logic with one important change - it should NEVER overwrite any file listed in NoUpgrade.
That's what I did.
By default there should be NO NoUpgrade list in pacman.conf. There is no point to include any _config_ file in NoUpgrade, _only modified system shell scripts_ should be included there (for some rare cases when user modifies them).
I agree.
When package that owns file listed in NoUpgrade is removed - this file should be saved as .pacsave.
Yep, but I was asking about the current pacman behavior, since I couldn't try it. Having a second look at the code, it finally seems it's already what happens, so it's fine.
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
participants (4)
-
Jason Chu
-
VMiklos
-
Xavier Chantry
-
Роман Кирилич