Part of making a new deployment involves merging /etc in the booted deployment with /usr/etc from the new deployment to generate /etc in the new deployment. This is safe to do when the system is booted, but any further changes to /etc on the booted system won't be reflected in the new deployment and will therefore be lost after rebooting.

This would be at the minimum confusing to a user and at worst rather problematic, since e.g. creating a new user after a deployment will result in the home directory staying but the entries in /etc/passwd and /etc/shadow disappearing after a reboot.

The simple solution is to make the deployment on the shutdown path, but this can be quite slow (> 5 mins) on slower rotating disks or emmc storage. Blocking shutdown for this long isn't a good user experience.

The best solution I can come up with involves splitting the deploy step into a few pieces that run at different times, but it doesn't fit the existing API structure well at all. It would look like this:

While the system is running normally:
1. Do the first half of ostree_sysroot_deploy_tree(), specifically the part up to and including calling checkout_deployment_tree(). This is the first slow part.

When the system is shutting down:
2. Do the rest of ostree_sysroot_deploy_tree(), which includes a call to merge_configuration(). This is pretty fast.
3. Run most of ostree_sysroot_simple_write_deployment(), especially the call to ostree_sysroot_write_deployments(), to update the bootloader entries. This is very fast.

When the system has next rebooted:
4. Run ostree_sysroot_cleanup() to clean up unused deployments/objects. This is the second slow part.


The slow parts (1) and (4) can run in the background, and only (2) and (3) have to run in the shutdown path.

Does that sound like a reasonable fix for this issue, or is there an approach that doesn't involve changing the api as much?