Following the recent bash breakage, Pierre was wondering why the /etc/profile just stayed there on the filesystem : http://www.archlinux.org/pipermail/arch-dev-public/2007-December/003556.html I didn't understand this at all. As stonecrest noted earlier, when the "current" mirrorlist was removed from pacman package, that file totally disappeared during the upgrade, even though it was in the old backup array : http://www.archlinux.org/pipermail/pacman-dev/2007-September/009376.html This caused the following commit : http://projects.archlinux.org/git/?p=pacman.git;a=commitdiff;h=843d368ef60a7... The first part of this commit is supposed to temporarily add all old backup entries (besides the new) to the NoUpgrade array. Because of a bug, it didn't have any effect. The second part was an idea of me to handle the pacsave during an removeupgrade just like we already did for a remove, but I finally think this is a really stupid / misleading / confusing idea. This code shouldn't even be reached during a removeupgrade if the first part was fixed anyway. So that was just a little sum up, now description of the bug: alpm_pkg_get_backup(newpkg) : newpkg is the one that will be installed, so this only return a list of elements like "file" alpm_pkg_get_backup(oldpkg) : oldpkg is a locally installed package, so this return a list of elements like "file<tab>md5sum" Since the md5sum wasn't removed there, adding these files had 0 effect. Now, this can easily be fixed. But then all files in either old or new backup array that were in oldpkg but not in newpkg will just stay there on the filesystem. They won't be renamed to .pacsave . Why the bash case was different to the pacman one is that, even if /etc/profile was removed from the newpkg, it was still in the backup array of the newpkg (which is the only one pacman looks at). So the file wasn't removed and was just left on the filesystem. Even though the bash case is a packaging error, it's a real case that happened, so it might be worth adding it to the pactests.