<cjwatson> sergiusens: I'm pretty confused about how the "architectures" field in a snapcraft.yaml is meant to work. It seems to override the architectures of the generated snap package, not specify which architectures the snap might be built for - is that right? <sergiusens> cjwatson, architectures in snapcraft.yaml should probably just go away; it is only there since people wanted it on special request (using prebuilt binaries and manually constructing a fat package). <sergiusens> but yes, it is an override, not a "built this for" :-/ <cjwatson> sergiusens: Have you put any thought into metadata that describes the architectures that the source code for a snap can be built for? It would be useful for the LP/store interaction. <cjwatson> sergiusens: debs have this for a reason ;-) <sergiusens> cjwatson, can you log a bug, I agree, but I'll forget https://bugs.launchpad.net/snapcraft :-) To elaborate on this: it would be useful to be able to make a single build request to Launchpad which would build the snap for all architectures it supports. At the moment you can configure this in Launchpad, but it really belongs with the snap's metadata instead. Each individual (non-fat) snap that comes out of this should still have just a single architecture in its metadata. As with debs, there should be a value that indicates that the snap is portable code that you can build anywhere reasonable (like "Architecture: any"). It may also be useful to have a value that indicates that the snap only needs to be built once and will then consist of architecture-independent code that can be used on any architecture (like "Architecture: all"), although I don't know how common that situation is given Snappy's approach of bundling everything.