On 9/18/07, Xavier <shiningxc@gmail.com> wrote:
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 ?
What would seem smart to me: 1. If file has been removed from backup array and no longer exists in the package, save it as .pacold. 2. If file has been removed from backup array and is still in the package, install new package as pacnew. Does this seem valid? -Dan