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 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](https://github.com/rpm-software-management/rpm/commit/26389a69ac37f37dd35b12ef340316dc903b3955),
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.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3409
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/repo-discussions/3...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
