Mixer fails to reuse workspace if upstream delete bundles

[mbelluzzo]

If you are only tracking upstream (IOW mixer bundle add --all-upstream) and reuses the mixer workspace between builds, mixer init will fail when bundles are deleted.

mixer init --upstream-version 29690
mixer bundle add --all-upstream
# a given build, no need to actually build to trigger the error
# later, on a following build
mixer init --upstream-version 29800 #to reset to new version
Initializing mix version 10 from upstream version 29800
2019/06/06 05:15:53 ERROR: Cannot find bundle "kernel-container" in local or upstream bundles

[rchiossi]

why are you running init on top of an existing mix? Do you need anything from the first initialization?

[jwakre]

Even if the 2nd mixer init is replaced with mixer versions update, downstream mixes have trouble detecting upstream bundle deletions:

mixer init --upstream-version 29690
mixer bundle add kernel-container
mixer build all --native
mixer versions update --upstream-version 29800
mixer build upstream-format --new-format 28
mixer build all --native
2019/06/06 13:22:23 ERROR: Couldn't build bundles: Error building bundles: Cannot find bundle "kernel-container" in local or upstream bundles

[rchiossi]

Answering over the phone is not helping... twice I missed what was going on. I'll get back to it when I get home.

[mbelluzzo]

mixer init is one of the ways to get to the issue.

Calling init always has other value: sanitize the build environment. Only mixer knows if the state of its workspace is in good shape. You never know when a crazy monkey went by and flipped a bit, removed a file, changed a format.

[jwakre]

The mixer init and downstream format bump failures seem like separate issues, so I created #694 to track the format bump failure.

[reaganlo]

@mbelluzzo The problem here is that mixer init does not clear the mixbundles file. I'm not sure why it was designed like that. But we could make that change if required.