On Sun, Jan 16, 2022 at 5:05 PM Chris Adams <linux(a)cmadams.net> wrote:
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.
I'm not expecting to do filesystem rollbacks to revert Firefox or
SQLite. I expect if I have some kind of boot or startup problem, the
system is a candidate for a rollback. In such a failure, I haven't run
any other programs yet that may have upgraded a database.
Could modification to something in /etc result in startup failure?
Yep. Is a full system rollback really called for here? It'll work, but
it's a hammer. So maybe services need to learn to be a little
suspicious of /etc configs, and fail safe? Maybe system critical items
should be able to fall back to /usr/etc?
--
Chris Murphy