search

silitics / rugpi

An open-source platform empowering you to build innovative devices around customized Linux distributions.
https://rugpi.io
Apache License 2.0
35 stars 1 forks source link

idea: Option to delete overlay during installation #7

Closed reubenmiller closed 9 months ago

reubenmiller commented 9 months ago

An option to delete the overlay during the installation process to avoid mixing unexpected states together when using set-persist true.

Use-case

When using set-persist true, old state from the cold partition could cause interference when upgrading to a new image and switching back to the A partition.

graph LR
    1[A] --new image--> 2[B] --new image--> 3[A]

For example:

  1. On Partition A, activate set-persist true
  2. Install App1 v1 (as it was not part of the base image)
  3. Install new image and switch to Partition B
  4. Install new image (now containing App1 v2) and switch to partition A

The installation of App1 v1 in step 2 will override any changes to the new App1 v2 in step 4. This would prevent both compatibility challenges for the app, resulting in a non-functional app as it would mix files from the App1 v1 and v2 together.

In some situations, the state persisted when using set-persist true is only tied to the current image, and may not be relevant once a new image is applied.

In general images are used as a baseline to guarantee all of the packages work together to provide as one larger functional entity. Old stale overlay state (such as applications) should not corrupt its function.

Proposed solution

Add option when installing a new image whether any overlay partition should be deleted or not before the new image is started.

This would be a non-breaking change, and it would give the flexibility for image creators to decide whether they want to opt-in for this functionality or not.

The functionality could be exposed as a cli command in the install command:

rugpi-ctrl update install [--reset-overlay] <image>
koehlma commented 9 months ago

In general images are used as a baseline to guarantee all of the packages work together to provide as one larger functional entity. Old stale overlay state (such as applications) should not corrupt its function.

For this reason, I think it should actually be the default to wipe the overlay instead of keeping it. There would then be an option --keep-overlay (instead of --reset-overlay).

In general, the persistent overlay was intended for development purposes only and I rather clearly break something early (wiping the overlay) than potentially causing subtile incompatibility issues down the line.

koehlma commented 9 months ago

You can now use the option --keep-overlay to keep the overlay. Otherwise, it will be discarded to prevent any subtile issues due to incompatibilities from popping up later.