Relocating Fedora's RPM database
Relocating Fedora's RPM database
Posted Jan 13, 2022 11:22 UTC (Thu) by nim-nim (subscriber, #34454)In reply to: Relocating Fedora's RPM database by matthias
Parent article: Relocating Fedora's RPM database
1. installation files (recreated on install, identical over many systems)
2. caches (transient stuff that exists to optimise performance and can be lost)
3. valuable data (the things that can not be recreated on install and are worth saving)
It‘s a triptych not a diptych.
The third category is usually the smallest in size but the most valuable. It is hard to manage so the temptation to pretend it does not exist (or will be managed by someone else, usually the cloud nowadays) is permanent
Putting 3. in /usr can not work unless /usr is redefined as something that does not fit static installs.
3. is also often pre-seeded from static installation data and it is tempting to conclude that because pre-seeding makes it “almost” installation data is can be conflated with installation data but that does not work in real life (real life test: what happens when the filesystem is wiped out).
Also a lot of apps do not support layered preseeding, preseeded data has to be deployed in the “valuable data” space on install, not in the “static data” space.
A lot of systems do not make the effort to separate 1. 2. and 3. they are in the 90% almost working category.
But 90% almost working is known as never working from the user side.
Posted Jan 13, 2022 11:36 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (3 responses)
Posted Jan 13, 2022 16:33 UTC (Thu)
by smoogen (subscriber, #97)
[Link] (2 responses)
Posted Jan 13, 2022 17:07 UTC (Thu)
by dbnichol (subscriber, #39622)
[Link]
Posted Jan 13, 2022 19:45 UTC (Thu)
by walters (subscriber, #7396)
[Link]
Posted Jan 13, 2022 11:51 UTC (Thu)
by taladar (subscriber, #68407)
[Link] (3 responses)
Posted Jan 13, 2022 18:02 UTC (Thu)
by rfunk (subscriber, #4054)
[Link] (2 responses)
Posted Jan 14, 2022 16:48 UTC (Fri)
by jccleaver (guest, #127418)
[Link] (1 responses)
There's an argument that updated "permanent state" should go in /etc/, since package install/removal makes changes to things in /etc/ as well. Consider /etc/shells, which may be updated by the installation of a new shell package. Or any of the myriad other caches and records in there.
I'd support a move from /var/lib/rpm to /var/rpm, but I'd sooner suggest /etc/ than a new top-level directory for this. The prohibition on binaries in /etc/ is about executable programs, not binary caches or records -- especially not of things that correlate explicitly with package install/removal.
Posted Jan 15, 2022 15:33 UTC (Sat)
by luto (guest, #39314)
[Link]
Posted Jan 13, 2022 12:08 UTC (Thu)
by matthias (subscriber, #94967)
[Link] (1 responses)
Of course. I did not talk about your 1., as I was talking about /var and the installation files should be under /usr. And actually I would add a forth type: system configuration, i.e., the data usually found under /etc. Of course, configuration data is often valuable, but it is still different in the sense that it is also often system dependent. You cannot simply copy /etc to a different system and expect the things to just work.
> The third category is usually the smallest in size but the most valuable.
This depends on the use case. In many cases it is the largest in size by orders of magnitude. Our family photo collection alone is far bigger than 1.+2.
The valuable data is usually stored in /home, /var, or both, depending on whether it is managed by a user or by a system application (like a database engine). For the data in /home it is quite obvious that one wants to have a backup, but some of the data in /var is equally important. And having a backup of the system configuration under /etc is definitely not the worst thing either.
> A lot of systems do not make the effort to separate 1. 2. and 3. they are in the 90% almost working category.
Actually, the installation files (1.) are mostly separated under /usr. Whether this is a separate volume or just a folder does not really matter for most people. And for those who care this can be easily arranged as a separate volume. The mess is below /var and also below /home. In both places 2. and 3. are mixed up. Under /home there are, e.g., browser caches. Clearly not the most important thing to backup.
And I definitely agree that there should be some effort to separate these things. In this way, I really like much of the systemd development. All the systemd support for containers and stateless systems needs a clean filesystem layout. Fork a new instance by reusing /usr and providing a fresh (empty) /var. And they are also working hard on reducing the necessary configuration under /etc, thus that containers and similar lightweight systems can gather all necessary data from the environment (e.g. network configuration by dhcp) and /etc can be empty on system startup. Let's hope that they do not stop halfway and continue cleaning up. There is still some way to go.
Posted Jan 13, 2022 13:44 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link]
The next frontier is sorting out 2. and 3.
Posted Jan 13, 2022 13:25 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
And not that I had anything of importance there, I don't think, but I think I've just lost /var from my old system. And it had things like my personal wiki, I think the mail system stored a load of stuff there, etc etc. /var actually contains a lot of data (like other people said, databases), and its loss is NOT a minor matter.
I've now got into the habit of stashing most stuff in /home somewhere, but it would be nice if there was some way of separating stuff like user databases from other stuff like system databases (mail, printer spools, gentoo's installation stuff, whatever whatever).
Cheers,
Posted Jan 13, 2022 20:38 UTC (Thu)
by JanC_ (guest, #34940)
[Link]
Relocating Fedora's RPM database
Relocating Fedora's RPM database
Relocating Fedora's RPM database
Relocating Fedora's RPM database
Relocating Fedora's RPM database
Configuration and State
Configuration and State
Configuration and State
Relocating Fedora's RPM database
Relocating Fedora's RPM database
Relocating Fedora's RPM database
Wol
Relocating Fedora's RPM database