2007/9/19, Xavier <shiningxc@gmail.com>:
stonecrest noticed during last pacman upgrade that the /etc/pacman.d/current file was removed, although that file was in the backup array of previous packages, and might have been modified by the user.
pacman 3.0.5-3 contained only /etc/pacman.d/current file and had it in its backup array. pacman 3.0.5-4 contained only /etc/pacman.d/core file and had it in its backup array. And on 3.0.5-3 -> 3.0.5-4 upgrade, the current file is removed, without any backup.
While in this case, it was totally harmless, in the general case, it might not be the desired behavior.
As we know, in pacman, an upgrade is a remove + add progress. The remove is a special one though, since we dont want to lose the config files. So pacman adds all files in the backup array to NoUpgrade, so that these files are not removed. But it picks only the files of the new backup array, as seen there :
298 /* Add files in the NEW package's backup array to the noupgrade array 299 * so this removal operation doesn't kill them */ 300 /* TODO if we add here, all backup=() entries for all targets, new and 301 * old, we cover all bases, including backup=() locations changing hands. 302 * But is this viable? */
So during 3.0.5-3 -> 3.0.5-4 , the current file was not added to noupgrade and was then lost.
Implementing the above TODO would probably fix the issue, and it should be pretty easy to do. But I'm a bit concerned by the last comment : "But is this viable?" What are really the downsides of doing this?
While writing this, I may seen one inconvenient, it's that it might not be obvious to the user that this current file is no longer used and owned by pacman. Maybe it should be renamed to current.pacsave then ?
Thanks for bringing this up. I think it would be nice to have such files saved as .pacsave. But how many of those files (that were in NoUpgrade) still exist without backup information now? I think they are <0.1%. -- Roman Kyrylych (Роман Кирилич)