WARNING: This part of the ImageBasedUpgrades specification is still in active discussion.

Introduction

In the parent spec we cover how to do image based update of the Android system and the Ubuntu rootfs. Those two are typical read-only images that users aren't expected to modify on their devices.

However with the goal of convergence and the possiblity of running a full desktop system from a phone, we need to plan a way to allow users to install extra packages from the Ubuntu archive while retaining the possibility of doing image based updates.

This wiki page is here to cover some of the options and their pros and cons.

Options

UnionFS and extended dpkg to allow multiple state directories

Description

The idea here is to have a persistent file system used as an overlay on top of /. / would remain read-only most of the time but be moved to read/write mode when the user wishes to install extra packages.

The overlay would be written to some location like /data/local and so the partition backing / would remain untouched.

To avoid the obvious conflicts in /var/lib/dpkg when upgrading the base image, dpkg would have to be extended to allow for multiple paths to be checked and the extra packages would then have their own dpkg database under an alternate path (/var/lib/dpkg.local for example).

A userspace process (running from the initramfs?) would manage the process of applying the new base image, so we are not limited to file-by-file kernel resolution of any conflicts.

Pros and Cons (WIP)

Pros:

• Very similar to a standard Ubuntu system

Questions (WIP)

• How do we handle extra packages shipping triggers and requiring that trigger to be called when the packages in the base system change?

  • parse triggers database, activate any necessary triggers using dpkg-trigger, and dpkg --configure -a at the end

• What happens if an extra package diverts a file shipped by a base package and the base system is then swapped for a newer version?
  • parse diversions database and follow diversions when applying new base image

• What do we do if an extra package depends on inotify (knowing it's currently broken with overlayfs)?

• How do we deal with packages using debconf for key/value storage?
  • use debconf's existing stacked database support
• What happens if an extra package depends on a base package which is subsequently removed from a newer version of the base system?

  • before starting, require dependencies in overlay to be consistent, and check that dependencies will still be resolvable with the new image; after upgrade, run the equivalent of apt-get -f install (may not get the exact same version, but that's consistent with upgrading the base image in any case)

• What happens if an update to the base system brings an extra package which was already installed by the user but with different content?
  • similar to previous, but we'll need to remove packages from the overlay, and check that the version in the base image still satisfies dependencies; this may need to be done forcibly before starting the image upgrade to avoid file conflicts
• What happens if an extra package has file system conflicts with another package that was introduced in a base system update?

  • perhaps the base image should come with an aggregated list of Replaces, so that we can determine whether the result is permissible?

Completely separate Ubuntu container/chroot

Description

The idea here is to avoid the whole Union FS complexity by simply shipping (or allowing users to download) another Ubuntu base system, which would be setup as a container or chroot on the device and on which the user would have full control. Updates of that system would be performed through apt+dpkg and it wouldn't be affected by base system updates at all.

Bind-mounts would be setup where appropriate to allow for that environment to access the user's data and the various daemons running outside of it.

Pros and Cons (WIP)

Pros:

• Isolated, no conflict resolution to do when the base system is upgraded.

Cons:

• Uses twice the disk space on the device (though it wouldn't be there by default)

Questions (WIP)

OSTree

Can we leverage OSTree for this? More analysis is needed.