Dne 12. 01. 22 v 22:05 Chris Murphy napsal(a):
On Wed, Jan 12, 2022 at 2:04 AM Panu Matilainen <pmati...@redhat.com> wrote:On 1/12/22 10:45, Chris Murphy wrote:On Tue, Jan 11, 2022 at 2:00 AM Panu Matilainen <pmati...@redhat.com> wrote: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 /usrIf 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.WTF is this talk about constraining? There's no such constraint in rpm, and never will.I'm not talking about changing the nature of the beast. I'm talking about how it's used as a tool in a distribution with a lot of other requirements and tradeoffs. Expanding rpm is also a valid path. We have an example "DNF snapper plug-in" that demonstrates at least DNF *could* get into the business of managing snapshots and rollbacks, if it wants that responsibility, if it's helpful and worth the effort, and if the resources exist to do it. That's an interesting discussion.And Fedora packages are not constrained there either, a vast percentage places stuff in /etc, touches directory tree in /var and then there's /boot and the software collections and third party software./boot might need its own manager(s). I'm strongly leaning toward bootupd and fwupd being the only things that touch /boot and everything else is proscribed. /boot is a small but hot mess right now. RPM, grub, grubby, dracut, all can touch /boot and in the Boot Loader Spec context there's multiple OS's sharing /boot. About the only thing I like better is linux as the bootloader, e.g. Linux Boot, so we have real device and file system drivers. Anything that manages /boot needs to needs understand snapshots, and which kernel+initramfs can boot which snapshots.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.Erm. Packages don't live conveniently inside a single top level tree, they can't be split up that way.Right. I view this as a criticism, not a benefit though. Neither rpm nor the FHS are organizing things in a way that helps us do rollbacks. They're impediments we keep having to take other shortcuts and workarounds to achieve that goal, and as yet they still have too many shortcomings. It really isn't to be underestimated the importance of multiple independent parties coming to the same kinds of conclusions.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.Here seems to be another SMALL undocumented dependency of this change: completing the /usrmove thing to cover the whole world including /opt, /etc, /var, and presumably /boot as well because packages put stuff in it. Rpm wont care if you want to move content from /etc to /usr/etc and ditto for /var, /opt and /boot which is also used by packages, ie to complete to complete the great /usrmove thing started a decade ago. But that's quite a hidden agenda in this change if you ask me.This change proposal is narrow in scope. It imagines a future snapshot+rollback regime of some kind, but isn't depending on any particular file system or way of achieving it. I personally like the transactional updates approach. I like what rpm-ostree is doing, updating the system root out of band rather than updating the currently running system.
Actually, shouldn't rpm-ostree carry around some copy of the RPM database, which would describe the state of /usr and once the update is successful (or snapshot active?), merge it into the main system RPM database? Apparently, something like this is already happening e.g. for /etc content if I understand it correctly. Or this is the direction in which the /boot will be handled eventually. Or possibly it could be just some linked (possibly just read only) database.
IOW, imagine, that we still keep the system read/write RPM database in /var and we teach RPM to use additional database(s). So RPM would know that there might be some additional database e.g. in /usr/var/ ... The system database would not know nothing about content of /usr, but once /usr was mounted, `rpm -q` would provide the information from the linked RPM database.
Vít
I like the idea these updates can happen in a container, if they fail for any reason we just remove that bad tree - it's a completely disposable thing until it successfully updates and maybe we can even automate some simple tests (it gets to X milestone in the boot process) before we activate it as the current root. I like the idea of users being able to follow the trail of breadcrumbs of how systems boot. My strong bias from many years in Fedora QA is we deal every cycle with boot/startup failure in some form or another, and the less obscure less fragile more self-describing and standard that process can be, the easier it is to avoid, find and fix problems. We also know that (open)SUSE has proven a working boot to snapshot design. It's just complicated. They're the first to admit it, and that they've learned a lot from the experience. Things have changed in 10 years. I imagine we're wandering in a very big library and we don't know exactly what book we're looking for, but we're perusing with a purpose. If there is a hidden agenda, it's because none of the change owners are attached to any one particular boot to snapshot design. We know it's not going to look identical to anything else out there because it has to work with a purpose for Fedora, but we also don't know the details of what that's going to look like. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
