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. Moving the RPM database to this tree adds a
component that is 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". 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.
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, it's updated by tools we run all the time, and it's
stateful. Losing it would render the system not really useful, though the
system would still function. Am I missing anything here?
As Lennart noted, we have lots of examples in /usr of changing data. But I'd
say the difference between those examples (library symlinks, cache files, etc)
and the RPM database is that the loss of something like a library symlink or
cache file can be repaired easily but if you lose the RPM database, the system
is in an unrepairable state.
As another example... If you use Bitlbee, this would be like losing your
account XML file in /var/lib/bitlbee. Sure, bitlbee still works, but that
file is important for Bitlbee to work for you. You have to remember to hang
on to that if you wipe /var or reinstall or whatever. I'd say the Bitlbee
files in /var/lib/bitlbee also fit this slightly different /var data
definition, just as an example.
"But what about the FHS?"
Ah, yes, the FHS. So, I am a fan of the FHS. I actually don't care that it
doesn't change every week and is relatively stable. Nothing in the FHS
prevents the addition of new top level directories.
I would prefer we steer this conversation in the direction of determining a
new top level location to store data that fits this category of "stateful but
variable".
/srv was introduced to provide a consistent location for data in this category
for server daemons (except mail).
/media was introduced to provide a consistent location for removable media
mount points since distributions all did things slightly differently.
/run was introduced for what was traditionally in /var/run.
"So what are you suggesting?"
I would like to see Fedora introduce a new top-level directory called:
/state
That holds the RPM database and other variable and stateful data. This keeps
it out of the /usr tree and can serve as a location for future data in this
category.
--
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
