Changing the base doesn't change the build VM

[Kyle Fazzari]

Once snapcraft creates a build VM, changing the base has no effect-- it continues to use the build VM it initially created, even though it now corresponds to a different base.

[Claudio Matsuoka (cmatsuoka)]

I see a few different ways to deal with this situation, and we must choose one that better meets the product goals taking into account implementation effort for a situation that's probably not very frequent.

Our options:

1. Determine if base is outdated. If so, issue a warning telling the user to clean and retry.

2, Determine if base is outdated, then clean and retry automatically. Harder to implement, can add complexity to lifecycle processing.

3. Add a base identifier to the build provider ID (e.g. snapcraft-foobar-core18 instead of snapcraft-foobar). Base changes are handled automatically, but one extra provider is instatiated. Implementation cost is very low, and base changes should be rare. Acceptable?

[Claudio Matsuoka (cmatsuoka)]

Despite being the easiest implementation, option (3) causes internal inconsistencies: a project could have multiple provider instances for different bases, and cleaning a project would only remove a provider instance for the current base specified in the yaml file. This leads to potential stale VMs that won't be removed by snapcraft clean, and general breakage of the original provider tracking design.

Option (1) is the next candidate.

[Claudio Matsuoka (cmatsuoka)]

In an unexpected plot twist, it turned out that effort needed to implement (2) is very similar to (1), so for user convenience let's do it automatically.

Proposed fix: https://github.com/snapcore/snapcraft/pull/2460