On Mon, Jan 10, 2022, at 11:19 AM, David Cantrell wrote: > On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: >>https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr >> >>== Summary == >>Currently, the RPM databases is located in `/var`. Let's move it to >>`/usr`. The move is already under way in rpm-ostree-based >>installations, and in (open)SUSE. >>[snip] > > Moving the RPM database to /usr feels incorrect to me, but we should move it > to gain the improvements as noted in the feature proposal. > > Numerous followups have noted the requirement that /usr contain read-only > content, that it be shareable across hosts, and similar concepts. While this > may or may not doable now like we could in the past, the bigger thing to me is > around the understanding of what /usr contains. It is generally understood > that /usr contains [most of] the installed system. What I think is a bigger > requirement or expection now is that one can tar up /usr and transport it to > another system or virtual machine or container and expect that it will > _probably_ work maybe with a bit of tinkering. This is a really valuable > thing to have for developers. No, this is not about developers tar'ing up `/usr` by hand. It's about cleanly separating who owns what, and what its lifecycle is, which is critcially important for both "image based" updates as well as "local client side snapshots". Both these approaches end up creating more than one copy of certain files. See - https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/ - http://lists.rpm.org/pipermail/rpm-maint/2021-December/018770.html > Moving the RPM database to this tree adds a > component that is unnecessary and sort of out of place. I struggle to how to even respond to this. Multiple independent groups who *actually work* on image based updates and/or client side snapshots all generally agree that the rpmdb should be in /usr. That's where this Change came in. On what basis are you making this claim "unnecessary and sort of out of place"? > > "OK, but you can do tar -X" > > The tar example was simply that, an example. I feel the categorization of > system data is more important here. Panu brought this up on the referenced > RPM mailing list thread years ago. The original /var location for the RPM > database was fine, but we're at a point where we kind of have multiple > categories of things historically found in /var. > > Reading comments and talking to people, the long standing understanding of > /var is still "that's stuff you can rm -rf and the system will still work > fine". Yes, we call this "factory reset". https://github.com/coreos/fedora-coreos-tracker/issues/399 I am not sure where the terminology came from, but it is widely used when talking about e.g. mobile phones today. > Technically you could remove the RPM database and the system still > function, but arguably would still be broken since you really want the RPM > database. This use case of removing the RPM database and still having a > functioning system is really only useful for data recovery scenarios. You're > ultimately going to reinstall. Probably. At least from my PoV, the rpmdb is by default read-only (except to rpm-ostree) along with the rest of /usr, so you can't just rm -rf it alone. > So maybe the question is more "what is the correct location for data like the > RPM database?" First, how is that data different from the rest of /var? It > is host-specific, No. An image based updates model (both ostree and container images) ships a pristine copy that is bit-for-bit the same on every system. Container runtimes tend to make it mutable by default of course, but that doesn't change the fact that it's not by default host specific. > I would like to see Fedora introduce a new top-level directory called: > > /state We have years of investment in rpm-ostree in the current design. For example, the tooling supports `rpm-ostree db diff` which shows you the delta between the current and pending rpmdb. How would this new directory work? How would it better solve problems that are today solved with the location in /usr? And do you even have a sense of how much work would creating for the rpm-ostree stack at least with a new toplevel directory with new, as yet ill-defined semantics? _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
