Updating the L5 (OTA)

Once the L5 is delivered to our hands we will find bugs and missing features, and Purism will provide updates.

Since 2015, I’m using an Ubuntu based mobile phone (as daily driver) and regular updates have been provided by Canonical and now by an OpenSource community (ubports.com), IIRC, I received 15 updates from Canonical and already 9 from UBports. They’re coming over the air (OTA) and the update is relatively easy and an automated process of download, install and reboot.

How is this planned for our L5?

It would be interesting to know if updates come based on system images (written to two alternating partitions, and wasting space) or regular .deb packages.

My guess is regular pureos .deb package updates.

This makes it very interesting to know, though, if the flash is getting nicely protected against wear and corruption by running things in RAM and only saving to flash in intervals or after update events completed. (For example, like in alpine linux.)

On my Ubuntu Touch devices the system partitions are mounted read-only and you should not modify this (ofc you can remount and write, but you should not to not break future OTA which are full tars). All your data is below phablet‘s home writeable or on SD. I have in addition below home a complete system to do chroot into it and compile/install/test there stuff to not touch the read only system.

In the near future, you’ll have classic deb updates (as can be tested with the VM images or dev kits) and flatpak updates for the apps.

In the far future, everything is possible :wink:

1 Like

Oh, already targeting advances like atomic and reproducable packages, great!

The GUIX packager comes to mind, maybe it can be made to build packages from .deb source package definitions for a transition.

I think a phone is not a computer and the average user will endup in a non working or even bricked device if he/she just goes ahead and installs any dep file he finds interesting.

Yes, but I think what the laptop or phone working/testing channels provide in the end would be a separate question. Whereas the reproducible builds, defined system states, atomic installs, dependency handling, binary patch updates, and of course roll-backs could considerably benefit a free phone system’s reliability and manageability.

So actually, the guix package manager could make software-bricking of devices a thing of the past.

In that case Nix could be helpful too. I do not know much about Guix but it seems to be comparable to Nix.