On Fri, Nov 18, 2022, at 12:35 PM, Timothée Ravier wrote: >> No, the install script install script in an RPM trigger, so the write is >> still carried out by RPM. >> >> I don't agree. Just because a user can mess with files on the system >> doesn't mean the rpmdb is a lie, nor is it reasonable to go recheck all >> paths on the filesystem just in case they've done so, or create a daemon >> to provide an interface for doing that. > > Note that this change here is only about Fedora Silverblue & Kinoite > (and maybe IoT later). In those variants, /usr is read only and not > expected to be changed by users. The rpmdb is thus pretty much > guaranteed to match the content of the system by design for /usr. > > On rpm-ostree based systems, system composes (image builds), package > installation and updates are done "offline" so /boot is not available. > The bootloader is not updated by an RPM trigger and this is why we need > an additional tool to perform the update at another time. We've created > a daemon because we need the update to be reliable so it should not > fail if your SSH connections fails or if you Ctrl-C it in the middle, > etc. This daemon is really small I wouldn't even call it a daemon, at least not really. More in: https://github.com/coreos/bootupd/pull/401/files That said, I think Robbie is effectively saying "bootupd seems over-engineered" and that's not *entirely* wrong. It certainly could be simpler; yes, in theory we don't strictly need `bootupctl validate`. But...things like having status information going to the journal in a reliable fashion have proven *very* useful in the past. Most classically of course, dnf/apt type systems don't do this and it definitely makes things harder to debug after the fact. The discussion about offline versus live installs touches on https://github.com/coreos/bootupd/issues/108 and we probably should have an option to do that. _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
