Shared directories are not properly cleaned when partitions are enabled

[mr-cal]

What needs to get done

• Redesign the state manager to track the partition where files are located
• Redesign the clean_shared_area() function to remove the correct files from the list of tracked files from the StateManager's state files

The solution could leverage the data structures added by #664.

Why it needs to get done

If the same file exists in multiple partitions in a shared directory (stage or prime), cleaning doesn't work as expected. It will indiscriminately remove the file from all partitions. See this test for an example.

This is because the StateManager does not track files per-partition.

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/CRAFT-2928.

This message was autogenerated

[mr-cal]

Background

This was not an issue in the first implementation of partitions #517.

This issue arose when we got the unexpected and rushed requirement to redesign (#620) and evolve the first implementation. We documented it in ST106:

[StateManager support] will not be part of the first implementation of this spec. It needs to be more thoroughly defined.

Next steps

@cmatsuoka and I have discussed this at length and failed a few times via CRAFT-2583. There is no simple or non-hacky solution.

The StateManager is designed to work with a single lifecycle with a single set stage, prime, and install directories. The StateManager is tangled in the lifecycle execution from top to bottom - there is no clean API separation.

Partitions are an incomplete implementation of a grandiose concept of multiple lifecycles. Lacking multiple lifecycles, partitions are simply embedded into the execution of a single lifecycle. Because of this, there isn't a good design for the StateManager to handle partitions or even clean files from a partition.

A hacky solution is to make the files and directories properties of the StateManager a nested data structure that tracks files and directories per-partition. @cmatsuoka isn't in favor of this workaround.

The correct solution would be a refactoring of craft-parts to properly manage multiple lifecycles. In this case, partitions would not be an opt-in feature but part of the standard design.