Florian Weimer wrote: > * Colin Walters: > [...] >> 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-(
Yes, that's a PITA. However, I'm sure if we wanted to invest some brains the mechanism could be made smarter to figure out what is actually safe to apply live somehow. >> 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. AFAIK at least for SLE Micro which uses the same tech as openSUSE MicroOS ie transactional updates, customers are expected to install extra software as container. The OS is not meant to install rpms from sources other than it's own repo. So for that product it was an explicit decision that rpm is only for OS stuff. However, that policy only applies to the host. Inside containers rpm can be used in whatever creative way as usual. Anyway, what's happening is that in order to make OS updates more robust, a stricter separation of what is OS and what isn't gets implemented. The read-only bits of the OS have converged into /usr nowadays¹. It's expected to be kind of self contained. Systems can now even boot with empty /etc and /var as everything needed in there gets bootstrapped from content in /usr. If rpm is used to manage /usr content, all required information for that needs to be in /usr too and rpms have no business outside /usr anymore. Since rpm keeps package information in the rpmdb, the obvious next step is to demand moving the rpmdb to /usr. I think a reason why that doesn't feel right is because the rpmdb is a single binary blob that mixes different kinds of data. Maybe it could be split up. Package headers could be considered original data, strictly bound to the files the header refers to. So for OS files the headers would belong into /usr. Name indexes etc however are derivative data that can be reconstructed from headers. As such could be stored in /var and generated when needed², eg when actually installing packages or after rollback. I've suggested storing headers separately here: https://github.com/rpm-software-management/rpm/issues/1151 I acknowledge that the title is misleading though as that doesn't mean no database, just different format :-) If the headers are stored where the files are that would open the possibility to define additional prefixes such as /opt or /usr/local with their own headers. The database in /var could merge the information to have a unified view. That would allow to have /usr read-only while still being able to install 3rd party add-ons in separate locations. cu Ludwig [1] https://lnussel.github.io/2020/12/16/fslayout/ [2] File flags (eg skipped files due to --excludedocs) are computed and stored on installation time. Would have to think how and where to store that. Or maybe not support them in certain scenarios. -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Ivo Totev HRB 36809 (AG Nürnberg) _______________________________________________ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
