* Colin Walters: > On Wed, Dec 15, 2021, at 5:34 PM, Florian Weimer wrote: >> * Chris Murphy: >> >>> Fedora 36 seems like a good time to do this. What do you think? >> >> It's a bit odd to locate a database under /usr that isn't pre-built and >> installed. > > Why is that odd?
Mentally, I still associate /usr with something that can be mounted read-only from shared storage. >> I guess in theory there could be systems with a read-only >> /usr out there that still allow installation of packages into /opt. >> >> Does it really help to improve the snapshot situation? > > Yes. > > I didn't wake up one day and say "hey you know what, today I'm going > to move the rpm database just for fun". Neither, for that matter did > the OpenSUSE folks. We haven't had this conversation over and over > throughout the years just because it was some minor thing. > > What I *did* wake up one day and say I'm going to do is make upgrades > transactional and offline by default and hence safe. No one should > ever fear starting an operating system upgrade while their laptop is > at 30% battery. Administrators running important servers must be able > to easily roll back when the kernel *or* systemd (or something) else > regresses, because it's software, it regresses all the time despite > our best efforts. I appreciate these efforts. Although transactional-update (as documented below) seems have one major regression: transactional RPM updates now require reboots. 8-( > So yes again, this does matter. And it matters because whether you're > doing "image based upgrades" like ostree or just "client side offline > updates" like the > https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html > thing - it's very important *what data specifically* is > versioned/snapshotted and what isn't. On an ostree system for > example, it's completely normal that there are *two* rpm databases > (one you're running, one that's pending in the new root). > > All the data in the rpmdb is about content that's in `/usr`. That totally ignores Software Collections and packages from ISVs. If the expected future that RPM is going to be an OS-internal software deployment mechanism (and not be used for third-party software), it should not be a side effect of this change, but an explicit decision. Thanks, Florian _______________________________________________ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
