On Tue, Jan 11, 2022 at 2:00 AM Panu Matilainen <pmatilai@xxxxxxxxxx> wrote: > The problem with /usr/something is that the rpmdb is not specific to > /usr contents at all, and unlike any other content in there, so putting > it there just *feels so wrong*. That's what /state or /sysimage or, as > we now have, /var supposedly solves. > > I thought I'd suggested something at / level back then (in > https://lists.rpm.org/pipermail/rpm-maint/2017-October/006697.html > and/or > https://lists.rpm.org/pipermail/rpm-maint/2017-October/006699.html) but > seems like memory is failing me :) Maybe I thought it would seem too > outrageous to FHS believers to bother. > > The point was though, that the rpmdb is not at all the only data of this > kind and so having a dedicated home makes sense. > > For many practical purposes it's probably just rearranging the chairs, > but a separate top-level directory describing the *system* state seems > instinctively *much* more correct solution to it than stuffing it > somewhere deep inside a loosely related fs. If rpm is constrained to /usr, then its database can properly be somewhere in /usr If rpm is unconstrained, with transactions touching any of /usr /var /opt /etc, the resulting paradigm is inherently complicated, and an additional top-level directory doesn't help make it less complicated. Either top-level directories have their own databases, so rpm knows what's in them even if one is rolled back but not another; or there's one database to describe all of these top-level directories which then need to share a single (sub)volume so they're all snapshot and rolled back together. Either way, there's additionally a need for carve outs for things that shouldn't be rolled back. We have an example of the latter. (open)SUSE's current layout. There's a 10 line /etc/fstab, 9 of which are various Btrfs subvolumes to achieve the necessary carve out. It's sufficiently complex that the direction they're looking to go in is one in which rpm's only touch /usr. There's /usr/etc for read-only systemd defaults. And local customizations go in /etc. Much like rpm-ostree. Projects within two rpm-based distros independently came to realize that unconstrained rpm is difficult. Where rpm-ostree decided to do the hard work of actually becoming aware of the reality there's multiple system roots. > I don't understand the question. Rpm tracks and cares about all content > it knows about equally, regardless of the path. /usr is NOT special in > any way to rpm, it's just that most of *distro* content ends up in there > but a huge number of packages have content spread across /etc too. > > > I think rpm can't remain > > static for all time. It either needs to become aware of multiple root > > trees, and even mix and match top-level directories to create variable > > roots. And possibly even manage these things. Or it needs to constrain > > its reach to /usr and /opt. Whether /usr and /opt are tied together, > > or can be mix and match with their own rpmdb's, I have no strong > > opinion on. > > Oh, multiple rpmdbs. It's a while since that last turned up. It gets > tossed around as a solution but to me it looks like it brings more > problems than it solves. Given the choice, I prefer rpm only touches /usr, which includes /usr/var and /usr/etc. But if left unconstrained, having databases inside the directories they describe is more reliable than treating the database as a sidecar file that can much more easily become disconnected with one or more top-level directories it ostensibly describes the contents of. -- Chris Murphy _______________________________________________ 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
