Okay, so as @ikey mentioned we had a productive call yesterday.
There two main aspects that make this case interesting for us to explore further, as they diverge from the original ideas we’ve explored around base snaps:
- The interest on the base image is mainly to produce a small selection of derived images that will be under the control of Solus
- The base image is built out of a rolling release, which means it’s hard to promise ABI compatibility for snaps that use it as a base
As a short term measure, we can move forward with the base snap as-is, and review the snaps coming into the store that make use of that base to make sure they match the ones expected. This will unblock the immediate needs of Solus, and give us a chance to learn more and explore those use cases.
Then, as a medium term goal, we need to explore ideas to make the use of base snaps with rolling releases more practical. Even for the use cases of Solus, the lack of real guarantees that the application snaps that use the rolling base will remain working over time is not ideal. We can solve that by introducing the notion of “rolling base snaps”. As a strawman, imagine decorating the revision assertion when the snap is pushed into the store, so that this one revision of this one snap will always use that one revision of the given base snap. Of course, that implies we need the ability to install multiple revisions of a given snap in parallel, but that’s already something we have in our roadmap.
Another aspect we discussed, per the notes from @ikey above, is improving the review tools so that they can more easily detect breaking ABI changes in base snaps. That will be an interesting improvement regardless of the details discussed above.
Finally, we agree that more work is necessary to make it convenient to build snaps targeting different distributions, different versions of different distributions, and different base snaps.