Bug 771713
Summary: | RFE: Add a /var/lib/rpm-state directory | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Toshio Ernie Kuratomi <a.badger> |
Component: | filesystem | Assignee: | Ondrej Vasik <ovasik> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | ffesti, jnovy, ovasik, pmatilai, walters |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-01-12 14:16:44 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Toshio Ernie Kuratomi
2012-01-04 18:18:33 UTC
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. |