if i have a snap that was initially created as “architectures: [ all ]”, preinstall this snap on a core system and then eventually add a binary to that snap, i will have to switch it to i.e. “architectures: [ armhf ]”
will such a change be handled gracefully by snapd and will it just update the existing snap to the new one ?
Sounds like a worthy experiment!
My uneducated guess is that this will work as expected. I suspect the store maintains separate pipes for each arch, and an arch-all snap gets copied into each while an arch-specific snap only goes to one (or a few, of course).
So the armhf client will see the update, but non-armhf clients will continue to use the arch-all version without seeing an update.
Well i’d like to not “experiment” here, this is for a customer request 
The process you describe is indeed what i’d expect as well, but i wanted confirmation from someone from the core or store teams (snaps with only shell scripts for a device are way easier to handle this way, but it might happen that the customer will later include a binary)
Haha, make a new snap then! But yeah, official word would also ensure such behavior is not accidental and will continue.
Kyle is right - if this is a production environment, test it first. Always.
From a design perspective and also my understanding of where things stand, there’s nothing special happening in this case. If the snap is at the tip of the channel, it will be installed. snapd doesn’t know that this snap is “the same” for other architectures. It simply knows that it may be installed locally, and that it is the current recommendation.
