On Mon, Jan 10, 2022 at 01:24:20PM -0500, Colin Walters wrote:
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.
I was trying to give an additional example of what people may do with /usr and
the expectations around it. /usr contains data that comes from the
distribution. We drop packages in place and we get files from that. The RPM
database is generated and updated on the target system and represents the
actions of RPM on that system. This is why I categorize the RPM database
differently than the rest of what is in /usr.
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"?
See above. The RPM database contains data generated by RPM on the system in
question, it's not delivered to the user in a package or some other form.
The change proposal is about moving the RPM database to /usr. I am offering
my comments on why I think /usr is the incorrect location for this data.
"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.
Except removing a package would write that change to the rpmdb.
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.
We have other Fedora editions besides rpm-ostree. This change affects
everyone.
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?
The proposal has asked to move the RPM database. I don't think /usr is the
correct location. But I agree that /var could use some reorganization. I
feel we have an opportunity to define a set of data that represents the system
in question and define a more correct location from it while not redefining
/usr or /var.
Thanks,
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
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
