On Thu, Jan 13, 2022 at 8:49 AM David Cantrell <dcantrell@xxxxxxxxxx> wrote: > > On Mon, Jan 10, 2022 at 02:53:52PM -0700, Chris Murphy wrote: > >I don't see how /state solves the problem, rather than just > >rearranging the chairs. > > I've seen the rearranging the chairs comment in multiple locations now. If > the location doesn't matter, why can't the RPM db stay in /var/lib/rpm? It's all about consequences, not that it can't stay in /var/lib/rpm. The rpmdb could go in its own subvolume "rpmdb" mounted at /var/lib/rpm, and snapshot it at the same time as subvolume "root" which contains /etc /usr /opt. Each snapshot is a revision. And a way to mount matching revisions is needed if there's more than one snapshot to rollback. e.g. root-x86-64:fedora36.0 root-x86-64:fedora36.1 rpmdb-x86-64:fedora36.0 rpmdb-x86-64:fedora36.1 When booting root-x86-64:fedora36.1 the helper needs to 'mount -o subvol=rpmdb-x86-64:fedora36.1 --uuid=$fsuuid /var/lib/rpm' When booting root-x86-64:fedora36.0, the helper needs to 'mount -o subvol=rpmdb-x86-64:fedora36.0 --uuid=$fsuuid /var/lib/rpm' And for that matter, it could be state-x86-64:fedora36.0 and .1, mounted at /state. The helper could rewrite /etc/fstab, or develop a "discoverable subvolumes" systemd generator that assembles things per a heuristic. https://lists.freedesktop.org/archives/systemd-devel/2021-November/047063.html It's true that this change proposal doesn't go far enough. The issues with /var go beyond /var/lib/rpm. What about /var/lib/selinux? It's owned by the selinux-policy-targeted package. Even though the files may not change often, it probably needs to be snapshot and rolled back with revision matching for /usr and rpmdb. It could be done with a subvolume or another file system with LVM. There might be 6 of these carve outs. Instead of possibly 6+ file systems for LVM thin setups, there could be two: "system" is subject to snapshots and rollbacks, "variable" is not. The same "discoverable subvolumes" systemd-generator idea proposes working with plain directories using the same naming scheme, and would use bind mounts to just reassemble everything from those two file systems onto the FHS layout. Including read-only /usr. This was brought up on devel@ list a year ago and discussed at length, explains the difficulties with the many carve outs approach (open)SUSE has been using, and the various pros and consequences to go about simplifying it. https://github.com/lnussel/lnussel.github.io/blob/fs/_posts/2020-12-16-fslayout.md > These are valid points. My suggestion of /state (or another named top-level > directory...I saw /meta suggested somewhere, maybe LWN...but I kind of don't > want to imply references to Facebook) is on the basis of RPM operating with a > single database on a given system. The idea of multiple RPM databases is > interesting and I think there's value in discussing that, but that would be a > separate item for discussion. > > Right now, a system needs to support installation from the vendor, third party > repos, and local system packages. All with a single RPM database. So I > suggested /state to get that information out of /var but still keep it tied to > the host in question. I don't think /state is a bad idea. Maybe it suffers the same issue as this change proposal, in that it doesn't go far enough? > The /opt tree introduces another wrinkle. It's one that's never really gained > a lot of use in the Linux world, but where it has it's been treated as both a > place where vendors can deliver software and a separate /usr/local. I think > it's reasonable to assume vendor-delivered things in /opt can be thought of as > more independent than what's in /usr, but that's just an assumption. My most > recent views of things found in /opt from third party vendors shows that they > are self-contained trees built with the mindset of "I don't trust what the > system will provide me". I guess the main issue here for snapshots and rollbacks is, would it be ok to put /opt and /usr on the same lifecycle? They get snapshot and rolled back together? Or should /opt be a 3rd party playground and perhaps not even be subject to snapshots and rollbacks, it's entirely managed by rpm only? I don't know the answer to that. But I kinda like the idea of separate /opt with its own rpmdb. That way 'rm -rf /opt/*' is a valid way to reset the 3rd party location without messing up rpmdb because it too is cleaned up. > To move the RPM database in to /usr for the rpm-ostree snapshot and rollback > case would also imply restrictions around what a user can and can't do with > RPM on their system. If that's the case, then I would say rpm should stop > being a general purpose tool for the user and become a backend only tool run > by the OS. Let the users create new third party packaging systems to install > things on their own system. I'm not sure about this. -- 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
