On Mon, Jan 10, 2022 at 12:30 PM Frank Ch. Eigler <fche@xxxxxxxxxx> wrote: > > David Cantrell <dcantrell@xxxxxxxxxx> writes: > > > 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 [...] > > Considering that many other valuable mutable state are put under /var > are put there, databases, container images, etc. etc. etc, this > understanding cannot be correct. We could just leave /var alone. > > # sudo du -s /var/lib/* I *think* what David is suggesting here is that while databases and container images are indeed changeable data that lives in /var (and are likely VERY important to the user), they are not critical to the functioning of the operating system itself. The OS will still boot and you can still log in[1] if /var is wiped clean, though the system will probably not be doing anything useful at this point. Whereas if the RPM database is damaged or removed, a core function of the operating system (installation and updates) will no longer work. I think there is definite value in considering adding a new location (though it need not be at the top-level) for data like this. I'll note that the FHS states the following[2] in regards to /var: "Everything that once went into /usr that is written to during system operation (as opposed to installation and software maintenance) must be in /var." This exception seems to me to be clearly implying that "installation and software maintenance" do not need to be in /var (and as CoreOS has shown, there's value to keeping it somewhere else). A further quote from the same section of the FHS suggests the use of /usr/var, which is a location we are not currently using in the Fedora Project, but seems like it would fit the requirements for both CoreOS and traditional RPM Fedora. This same hierarchy could be used for /var/log and /var/lib/libvirt/images as well. [1] With the possible exception of enterprise logins, since SSSD stores its offline cache in /var/lib/sss/db [2] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05.html#purpose31 _______________________________________________ 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
