On 4/10/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Dan McGee wrote:
If this is it, then these should be the steps to reproduce (note that these reports are starting at step 5, the other stuff happened in the past): 1. Install a package that had a NoUpgrade line. 2. Edit a backup file. 3. Upgrade the package, causing the local md5sum to be written to the DB (instead of the original md5sum from the new package). 4. Do NOT edit the file again, and remove the NoUpgrade line from pacman.conf. 5. Upgrade the package, causing the 'original' and 'old' md5sum to be identical, which allows pacman to write an upgraded file over your custom config.
Possible fixes: 1. Put NoUpgrade lines back in. This is hacky/ugly IMO. 2. Back up all config files that are to be overwritten as .pacold files, even if they are supposedly legal candidates for overwriting. This will cause some clutter on systems, however, but will ensure no configurations are lost (although they would be moved). Confirmed, following Dan's instructions above I can replicate the problem.
Wow, I'm half surprised I got that right. :) Good to hear since I hate bugs that are not reproducible.
IMO option 2 plus a warning would be the best idea.
Andrew
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev This is kicking off because NoUpgrade doesn't store an MD5 of the original file in var/lib/pacman/local/*. If NoUpgrade is removed before
Dan McGee wrote: the package is upgraded with the appropriate backup=(..) line, pacman overwrites the NoUpgrade files. A solution I think... Short-term: 1. Put NoUpgrade back into pacman.conf ...let a little time pass... 2. Update all packages containing NoUpgrade files to include the proper backup=() line. 3. Tell everyone to go run -Syu ...let a little time pass... 4. Remove NoUpgrade lines from pacman.conf Long-term: NoUpgrade needs to work the same way as backup=(..). Andrew