Improving the offline updates user experience

Lennart Poettering mzerqung at
Wed Oct 22 10:27:47 UTC 2014

On Tue, 16.09.14 13:35, Petr Pisar (ppisar at wrote:

> On 2014-09-16, Richard Hughes <hughsient at> wrote:
> > The much bigger issues is if you're using a D-Bus service
> > like most applications seem to do (and most use quite a few system and
> > session, directly and indirectly) then you've also got to co-ordinate
> > and handle changing D-Bus API (which typically isn't versioned).
> Maybe it's time to version the API.
> Look at microkernel based systems which utilize messaging heavily and
> the API consumers (applications or another subsystems) have to be
> prepared for spurious API provider (server) restarts.
> A server can refuse a message any time (especially if it does not
> understand the request). Simple operations are usualy implemented as
> a sequence of requests and responses where initial request obtains
> a descriptor (a session, a handle) and subsequent requests passe it as
> context (a session) identifier. If the server is restarted in between,
> the context identifier becomes unrecognized and it's up to the
> application to deal with it.
> Just the fact that somebody calls functions over dbus instead of jumping
> into a shared library do not free them from maintaing API.

Well, the theory for this might be great. But reality tells us that
code that isn't regularly tested tends to be broken. Hence: the
assumption it would be reasonably possible to comprehensively test all
kinds of updates between any combination of software versions,
executed in any order, simultaneously with the user using the machine,
then is simply wrong. You explode the test matrix, and without testing
such upgrades will never be reliable.  The offline update logic is
about making the test matrix smaller, and adding determinism where it
normally is missing.


Lennart Poettering, Red Hat

More information about the devel mailing list