Re: Immutable Images: Updating

[Adrian Vovk <adrianvovk@xxxxxxxxx>]

> I figure this would be a 20 line patch. Would be happy to review a
patch for that.

Got it. That sounds reasonable to me. I'll get you a patch

> wouldn't it make more sense, to allow declaration of a "ReleaseNotes=" link inside a sysupdate .conf file, that can optionally take an URL parameter with the old and the new version? Then, rather than actually doing much client-side with this, we'd just show the formatted URL, and allow users to click on it before they do there thing. i.e. the diffing of the changelogs would be done server-side (if desired).

So the motivating factor here is integration with the GNOME Software
app. I want to present changelogs to the user in the app, and not just
shove the user off into the browser.

I'll need to give this a little more thought. Perhaps it could be
worthwhile adding appstream metadata to a system update, so it can
show up richly in the software center (and the appstream can include
changelogs). Thus we could have a ReleaseNotes link, and an Appstream
link that gives a machine-parseable appstream file to be consumed by
the graphical app store app.

> well, i'd make that "soft" coupling,

Yeah that makes sense.

> i.e. a downloader that recognizes it is writing directly to a partition would read a sector at the end of the partition, check if it carries some recognizable signature, and if so use the information from it to proceed with downloading only what's not downloaded yet. It would then keep updating that sector with far it has progressed.
>
> All this should be a hint only, i.e. it must verify hashes of what it downloaded anyway, and when it finds parts have already been downloaded it must verify they actually match expectations.

This all makes sense

> I don't grok this. Preqreq for what is what?

Prereq for upstreaming a GNOME Software plugin is that the update
mechanism is going to exist and be used in some reputable project.
They don't want plugins implementing functionality that will go
unmaintained

All I was saying is that by putting the dbus service in systemd, that
means the service is in use by a reputable project, so I could
upstream a GNOME Software plugin for it. If the dbus service was its
own project, I'd have a much harder time convincing the GNOME devs
that the dbus service will continue to be maintained

> rather than have users manually download a new release and upgrading to it, we'd always download it in the bg when available and all conditions to do so are met, and then just ask the user "hey, we updated, please reboot"

I will always prefer this as well. However, not all users want
auto-updates in this way.

At the very least, we should also report update progress to the users,
changelogs, and let users install updates faster than they would be
auto-installed

Letting the GUI app store also trigger updates has some other
benefits, for instance it manages notifications and it also manages
queuing updates for metered connections. There's other benefits too
(for example, putting an update on a USB drive and then advertising it
in the app store for users to install)

I'll talk to the GNOME Software people & the GNOME Design team, maybe
they can have a better idea how to integrate a sysupdate-esque update
model into the desktop environment

> a "systemd-sysupdated" that provides a dbus-interface (and/or varlink) around "systemd-sysupdate" makes total sense to me

This makes sense. I can work on this.

> So my idea was to eventually have "systemd-sysupdate --all" which would iterate through all places we might have DDIs:

Sounds reasonable. I can work on this as well.

Best,
Adrian