Description of problem: %ghost + %config leave the file behind after package removal. %ghost files are removed. %config files are either removed or backed up as .rpmsave. This is surprising and dangerous for users. Hapless victims trying to fix broken configuration by uninstalling and reinstalling the package do not get the default. If the combination of %ghost + %config is not meaningful/supported/expected, it would be nice to get an error message from rpmbuild. Version-Release number of selected component (if applicable): rpm-4.13.0.1-7.fc26 How reproducible: seems deterministic Steps to Reproduce: 1.specfile with "%ghost %config /etc/foo" in %files 2.build and install the rpm 3.touch /etc/foo 4.erase the rpm Actual results: /etc/foo still there Expected results: /etc/foo not existing
Previous report at https://bugzilla.redhat.com/show_bug.cgi?id=1508376
Yes, this is known and actually expected behavior - from rpm POV that is. For the impatient: the only difference between %ghost and %ghost %config is that %ghost %config file will not be removed on package uninstall whereas a mere %ghost will. Whether it was originally intended to behave this way is lost in history (but see below), but the combination of %ghost %config is commonly used for files which you *dont* want to be removed along with the package, such as log files. Yes it's misuse of sorts of course (logs are not config at all), but this is such a long-standing behavior that it's commonly relied on, so changing the behavior risks people losing data. Perhaps the bigger problem is that this "quirk" isn't properly documented anywhere. %ghost %config is certainly a bit of an oxymoron because %config implies certain behavior which just don't make any sense at all with %ghost. Leaving %ghost %config alone does go in the spirit of %config in the sense that %config implies valuable data that you dont want to lose, and since the file is a %ghost any content that might be there is by definition "user" generated (as opposed to packaged). See https://github.com/rpm-software-management/rpm/commit/233e4573d1d21a36d06874fea6c594428033802e for further background - the former behavior seems to suggest this wasn't originally intentional but since it had the *effect* of preserving the file people started relying on it for the purpose.