Once upon a time, Ben Cotton <bcotton(a)redhat.com> said:
== Benefit to Fedora ==
* The RPM database primarily describes the state of `/usr`. Storing
the databases in `/usr` will more easily facilitate OS rollback,
without affecting `/var`.
Rolling back to the start... this statement is only marginally true.
And "primarily" is a hand-wavy hedge that just pretends the rest doesn't
matter.
Ony my Fedora 35 desktop, I have things in RPM under a lot of top-level
directories:
$ rpm -qla | grep '^/.*/' | cut -d/ -f2 | sort | uniq -c
99 boot
2998 etc
14792 lib
43 lib64
97 opt
5 root
43 run
10 sbin
442175 usr
2036 var
Some of those are RPMs that should probably be updated, but some of that
won't go away. There's important stuff in /var and /etc, and even for
the stuff that could be blown away and recreated, most programs aren't
set up (or don't have permission) to recreate their directories.
You can't snapshot just /usr, make software changes, and then roll it
back, because programs in /usr have expectations about other
directories. The whole OS doesn't exclusively exist in /usr. What if
that /usr change was an updated version of MariaDB or PostgresSQL that
updated the DB file format, or even just a program using one of those
DBs that had a schema update?
The only way I see any benefit to trying to rearrange the RPM database
would be to split it up somehow, where it could be spread across
filesystems (but that still has the same consistency issue of rolling
back /usr without making the same rollback to /var and /etc).
--
Chris Adams <linux(a)cmadams.net>