Anthony Towns wrote:
How about doing the exact opposite of what dpkg does now? Preserve changes made to the file, but, if the file's deleted, reinstate it in "pristine" form? Your train of thought is then "Oh, hell, I've completely wrecked this file, I need to start from scratch. Okay, rm /etc/foorc, apt-get --reinstall install foo". It's straightforward for programs to work out which files need to be reinstated (check for existance), and in almost all cases rm'ing the file isn't already useful for anything. Cheers, aj
This seems perfectly logical to me, and this is not an uncommon state to be in. Just yesterday at work, a fellow developer wrecked his dupload.conf, and the only way I saw to get him a new one was to email him one. (maybe there's a better way, but I don't know it. purge and then install again maybe?)
Maybe we can add the deletion of files to| dpkg-statoverride|, or create something like dpkg-confoverride which would allow you to flag conffiles to be deleted on installation, or replaced with local copies on installation, which would appease people like Matthew who want to remove files and not have them reinstalled. Since this is the less common case, it seems ok that it will be a little harder to do.
But I do agree with hmh that the current state is inconsistent and bad, and we should decide on one or the other (conffiles or postinst)
I personally like conffiles better as it would allow you to do something like write a script that would query dpkg and find all the conffiles on your system and back them up. That way, you could have another script that would restore them to a new machine.
-- michael cardenas | lead software engineer | lindows.com | hyperpoem.net "Be the change you want to see in the world" -Mahatma Gandhi