A halloween story 👻

[pmatilai]

As you may know, RPM packages may contain something called ghost files. Or rather, the point is that the files that are not there. While this may sound weird to the uninitiated, this is actually quite a common need. Consider for example a log file that gets created when a software you packaged runs - you don't want to ship a file for that, but you'd want the file to be identified with your package, and possibly removed when the package is removed. Yep, that's what %ghost is for.

So %ghost file in an rpm package is a file that might exist in the buildroot, but the file contents do not get packaged at all, only the metadata like path, permissions etc are registered in the package. Originally this was the only supported case, later we added support for what you might call declarative ghosts - files and directories that never existed at all.

You can perhaps imagine, these entities that exist on one level and not on the other tend to cause all sorts of special casing around the codebase. A %ghost file is not created on install, because there's nothing to create it from. A normal %ghost file gets removed when the owner package is removed, as you'd probably want for some uninteresting runtime state data. But if you also mark it as a %config file, then it is left behind on package removal - as you'd want to do for more valuable data. That much seems simple enough, but there are all manner of weird questions waiting for those who stick their nose a bit too deep into the ghosts' business.

Such as myself, one day in the winter of 2012-2013. I was working on adding tests and cleaning up the %config and %ghost file management, when I suddenly ran into a %ghost that did not obey the rules. It was a %ghost %config but got removed along with the package. There didn't seem to be anything special about the package or the file, and I stared and stared at the code, not seeing how it could possibly behave that way. Of course, there's nothing a sufficient amount of printf()'s wont find (yes, I'm of that school): the reason that one file in that one package was behaving differently was that the sha256sum of the file on my laptop disk happened to match the sha256sum of the file that had been in the buildroot. Somewhere far away in the Fedora buildsystem, probably months earlier. That was a properly spooky moment, and the reason I call this a halloween story. A ghost identifying with its past self, or something.

Past the initial surprise, this was of course perfectly logical. Rpm thinks a modified %config file is valuable and is preserved on erasure, but an unmodified %config file is not valuable and thus is erased along with the package. Otherwise we'd leave an useless litter trail behind. And while %ghost file contents is not packaged, the metadata is, and for a file that exists in the buildroot, part of that metadata is its checksum. If there's a checksum, it's possible it matches with something. And if there's logic that depends on whether a checksum matches or not, it can trigger. It was just a special case somebody forgot to add. I ran into lots of those that winter, but this is one I'm unlikely to forget.

To this day, I don't know for sure whether this %ghost %config behavior is intentional or not. The commit logs from the early days tend to be terse and light on the level of information provided.