On Sunday, January 16, 2022 11:16:57 PM EST Chris Murphy wrote:
On Sun, Jan 16, 2022 at 3:59 PM Peter Boy <pboy(a)uni-bremen.de>
wrote:
> > Am 14.01.2022 um 23:51 schrieb Fabio Valentini <decathorpe(a)gmail.com>:
> >
> >
> > Wait, I thought this change was about making the path consistent
> > within Fedora variants?
>
> The question still is whether this is actually useful and beneficial.
If you value Fedora having a snapshot and rollback scheme of some
kind, it's useful and beneficial. If you don't, then the change is
neutral because it has not a single technical downside presented so
far - just emotive ones.
I'm a little concerned about what this increased writing to /usr, which many
people have on a SSD, will do. I have everything that gets written to with
any regularity on spinning disks. Everything else is SSD.
I have to agree with Chris Adams that rpms own things on many top level
directories. I have rpms that own programs/files that live on /opt and other
top level directories. I also agree that most programs cannot recreate their
directory paths and consider it's absense to be a catastrophic failure.
I also see things like kmail which uses mariadb as it's storage. It
occassionally contains migration scripts to change the format of the
database. It never has a migration script to go backwards. We do the same
thing with fapolicyd and its lmdb backing storage. We migrate forward, but we
never allow backwards migration. To roll back fapolicyd, you'd need to
snapshot /var and roll it back. But since /var has the mail spool and other
accumulated data, you'd risk losing lots of stuff if /var was rolled back.
I'd think the solution for image based distros is to put the rpmdb in /usr/
lib/rpm and bind mount it to /var/lib/rpm. Doing it this way means no changes
are needed.
-Steve