Comment 6 for bug 1582469

Thanks for the report Gustavo! I'll try to address your concerns one at a time.

(1): To understand the motivation here, we've been trying to make something that behaves similarly to `make`. That is, ideally it understands when things need to be rebuilt, and doesn't build them if it thinks it doesn't need to do so. If one wants to build again, one typically cleans the given target first. We did this since we thought it would be a familiar workflow: run `make foo`, get foo. Run `make foo` again without changes, get "foo is up to date."

Of course, this is where we're _heading_, not where we are. Make works pretty well that way, since its state tracking is pretty trustworthy. In contrast, the current dirty state tracking in snapcraft is still a bit rudimentary. For instance, it still says a given part has already been built/staged/stripped even if one adds a new `stage-package` to the part's YAML. There are of course other things missing from this as well, and we're adding them over time.

Keeping that vision in mind, assuming the dirty state tracking gets to where we want it to be, do you still want the re<step> and un<step> commands?

(2): The per-step cleaning is currently also per-part, where `snap` isn't part of the lifecycle. Are you simply expecting `snapcraft clean --step snap` to remove the generated snap?

(3): Yeah, this is a bug. No need to clean something if it's already gone.