Description of problem: Sometimes it's possible to write rpm scriptlets that start operation in one scriptlet but finish operation in another. One concrete usage is when updating a cache after a type of rpm is installed. The program that is run to update the cache only needs to be run once so the rpm package can use %post and %postun to write out a file flagging that the cache-creating program needs to be run and then %posttrans can actually invoke the program if that file exists (and delete the file after running). We need a place to store those files that pass state information from one rpm scriptlet to another. The FPC has recently approved use of subdirectories of /var/lib/rpm-state for a couple guidelines for this purpose. It would be nice to have one package that owns the /var/lib/rpm-state directory rather than multiple packages (each time a set of packages needs to save state). Could it be added to the rpm package?
Adding a single directory to the rpm package is not a big deal, but it doesn't really ensure the directory will be there when needed. On initial install, rpm itself gets installed relatively late in the process and there could've been any number of these "stateful" scripts executed by then. From that POV, filesystem package would be a better choice for the directory.
Makes sense to me. /me retargets to filesystem.
Makes sense ... added to filesystem package in filesystem-2.4.46-1.fc17 . Closing RAWHIDE.
OK so many years later, this is causing a bit of pain for us working on bootc, because we really want everything in /var to have a corresponding systemd-tmpfiles entry. There's a bit of a mess here because shipping a systemd-tmpfiles entry in the filesystem package would mean it "theoretically" depends on systemd from an RPM path ownership perspective I think. One avenue here would be to make it /usr/lib/sysimage/rpm-state or so...the historical choice of /var for this made some sense when the RPM database was in /var, but it no longer is. Alternatively because this is clearly only "runtime" data, we could use /run/rpm/state or so too. I guess though either way because this is effectively an ABI depended on by packages, we'd have to continue to ship /var/lib/rpm-state as a symlink to a new location. Although, if rpm ever starts executing scripts using containers like rpm-ostree does, we could synthesize it only for those scripts.
This is not anything rpm uses, cares or even knows about. You want to change it, you need to change the packages using it.
> This is not anything rpm uses, cares or even knows about. I understand the technical separation. > You want to change it, you need to change the packages using it. I don't think "change all the packages" is viable because in the general case it may include 3rd party packages. Do you have an opinion on one of the other paths? For now I did https://gitlab.com/fedora/bootc/base-images/-/merge_requests/92/diffs?commit_id=f3840319f37f9f14ea2ff58233580c5d9fbec36c but I'm not really happy about that one, because we still need to leave /var/lib/rpm-state in the default image, which prevents us from just doing `rm -rf /var/lib`. One possible solution here is to change rpm to automatically create it, and clean it up at the end of a transaction. Hmm I guess in theory one could change `%filesystem` to have a %transfiletriggerin that matches all filenames and creates it...but trying to do the cleanup we'd run into posttrans ordering probably.
Look, this is purely a Fedora packaging level invention. You want to do something about it, talk to FPC. Rpm will not start creating random directories.