Comment 3 for bug 1221844

In the original description it says: "If the client notices that its local value (channel_target) doesn't match the server's value (alias), then it should consider its internal version number to be 0 and do a full update to whatever is the latest version available in the channel."

I don't think the second half of this (i.e. "do a full update") should be interpreted as equivalent to `system-image-cli -f full` since this might not leave us at the highest version number for that channel. E.g. if an upgrade path goes from 0:200:201:304 because 200 is a full update and 201 and 304 are deltas, then adding -f full would leave you at build 200 since it would ignore all deltas on the path.

So I think the actual interpretation of this feature is this: if the channel the device is tracking has an alias, and its channel.ini file has channel_target key, and the alias != channel_target, set the build number to 0 before calculating the upgrade path. Note of course that we do *not* use the channel_target or alias in any other way. Specifically, we still track the actually channel name from the channel.ini file.

For example, let's say 'daily' is aliased to 'saucy' and we're at build 300. Further, let's say a normal update would upgrade us through the path 300:301:304 with the latter two being deltas. But now 'daily' gets aliased to 'tubular' (because the Tubular Tapir series was opened). The channels.json 'daily' channel would now have an alias of 'tubular', but the channel.ini file would still have a channel_target of 'saucy'. We clobber the build number to 0 and calculate the upgrade path along the 'daily' channel (since now we don't care what its alias is). This leads to an upgrade path of 0:200:201:304.

Considering message #2 above, I've gone back and thought that explicitly providing a --build flag should override it. I'll see if I can make that work, but it's not the highest priority.