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.