On Mon, Jan 10, 2022 at 5:20 PM David Cantrell <dcantrell@xxxxxxxxxx> wrote: > > On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: > >https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr > > > >== Summary == > >Currently, the RPM databases is located in `/var`. Let's move it to > >`/usr`. The move is already under way in rpm-ostree-based > >installations, and in (open)SUSE. > >[snip] > > Moving the RPM database to /usr feels incorrect to me, but we should move it > to gain the improvements as noted in the feature proposal. > > Numerous followups have noted the requirement that /usr contain read-only > content, that it be shareable across hosts, and similar concepts. While this > may or may not doable now like we could in the past, the bigger thing to me is > around the understanding of what /usr contains. It is generally understood > that /usr contains [most of] the installed system. What I think is a bigger > requirement or expection now is that one can tar up /usr and transport it to > another system or virtual machine or container and expect that it will > _probably_ work maybe with a bit of tinkering. This is a really valuable > thing to have for developers. Moving the RPM database to this tree adds a > component that is unnecessary and sort of out of place. > > "OK, but you can do tar -X" > > The tar example was simply that, an example. I feel the categorization of > system data is more important here. Panu brought this up on the referenced > RPM mailing list thread years ago. The original /var location for the RPM > database was fine, but we're at a point where we kind of have multiple > categories of things historically found in /var. > > 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". That's one interesting definition of "fine" if it's OK with wiping the system's (arguably) *only* non-disposable directory. > Technically you could remove the RPM database and the system still > function, but arguably would still be broken since you really want the RPM > database. This use case of removing the RPM database and still having a > functioning system is really only useful for data recovery scenarios. You're > ultimately going to reinstall. Probably. > > So maybe the question is more "what is the correct location for data like the > RPM database?" First, how is that data different from the rest of /var? It > is host-specific, it's updated by tools we run all the time, and it's > stateful. Losing it would render the system not really useful, though the > system would still function. Am I missing anything here? > > As Lennart noted, we have lots of examples in /usr of changing data. But I'd > say the difference between those examples (library symlinks, cache files, etc) > and the RPM database is that the loss of something like a library symlink or > cache file can be repaired easily but if you lose the RPM database, the system > is in an unrepairable state. > > As another example... If you use Bitlbee, this would be like losing your > account XML file in /var/lib/bitlbee. Sure, bitlbee still works, but that > file is important for Bitlbee to work for you. You have to remember to hang > on to that if you wipe /var or reinstall or whatever. I'd say the Bitlbee > files in /var/lib/bitlbee also fit this slightly different /var data > definition, just as an example. > > "But what about the FHS?" > > Ah, yes, the FHS. So, I am a fan of the FHS. I actually don't care that it > doesn't change every week and is relatively stable. Nothing in the FHS > prevents the addition of new top level directories. > > I would prefer we steer this conversation in the direction of determining a > new top level location to store data that fits this category of "stateful but > variable". > > /srv was introduced to provide a consistent location for data in this category > for server daemons (except mail). > > /media was introduced to provide a consistent location for removable media > mount points since distributions all did things slightly differently. > > /run was introduced for what was traditionally in /var/run. > > "So what are you suggesting?" > > I would like to see Fedora introduce a new top-level directory called: > > /state > > That holds the RPM database and other variable and stateful data. This keeps > it out of the /usr tree and can serve as a location for future data in this > category. If I ever see a system with /state I'll automatically assume this is the only location that's not wiped on a reboot, invented because the admin gave up on denylisting useless stuff in /var. The whole proposal is kinda sad to read. It's 2022 and we're catering to filesystem-level rollbacks. Filesystem rollbacks *are* a gigantic unsubtle hammer that should not be used in an automated manner, or better yet, not used at all. As much as you don't do filesystem rollbacks to undo paragraph deletions in Libreoffice Writer, you shouldn't do filesystem rollbacks to fix your system. That's your package manager's / configuration manager's job. _______________________________________________ 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
