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@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to