There are several different aspects related to this topic which we need to take into account:
- What architectures the snap that was built can run on
- What architectures the snap may be built for
- What architectures is the snap being built for
- What base the snap that was built will run on
- What bases the snap may be built for
- What Linux distribution may the snap be built on
- What base should be used when the snap is built on a particular Linux distribution
The conversation so far has handled these topics somewhat implicitly, and at times it feels like some unintentional bridging between these ideas is taking place. This is worrying since people not participating in this debate will be unable to tell what particular aspect is covered and how to do what they want.
So, I propose we start off with a minimalist approach that focuses on the common cases and on a reasonable user experience for people doing the usual. For example, most people will not be building their snaps in multiple distributions, as by the end of the day a single snap will be pushed into store, and that single snap will be on a single base.
Also, it feels strange that we’re trying to separate multiple architectures upfront depending on the Linux distribution. In practice, the parts that compose the snap will in most cases define what architectures are supported by the snap, and these are not dependent on a particular distribution.
Along similar lines, the base will often be dependent on the system that is being used to create the snap instead of on the particular project being built. For example, if one builds a snap with packages from Fedora, it doesn’t make much sense to use a base that was created out of ubuntu 16.04.
So, circling back into the original point, I’m concerned about just putting syntax in without understanding in more detail the problems we’re solving and how people are supposed to use it (or how to understand it).
Perhaps we can take some apparently “safe” first steps:
- Define a system-wide default base internal to snapcraft. When not specified, snapcraft will attempt to build using a base that is appropriate for the local system if one exists, or complain if it can’t map the local system into an appropriate base.
- Accept a new optional “base” field in snapcraft.yaml, which allows overriding the system default and request that a particular base be used for the built snap (one base).
- Further explore why the “architectures” field is not enough. Having multiple architecture fields will certainly be confusing, so if this is not enough we need to write down the exact problems we have today with this field and fix those.
Does that sounds reasonable?