So I’ve uploaded my solus-runtime-gaming and got past the initial errors, but currently the store rejects base snaps and requires manual review.
Is this something that will be ongoing? I’d rather not have to go through that process for every iteration of the snap as it seriously impedes development and testing time. Perhaps some kind of authorised group for uploading base snaps after the initial review?
Cheers!
I think we can set you up so that your snap is approved. As this is us breaking new grounds with each step there are no established processes yet.
Yup - hence having the convo out in a place where it’s easily found for future reference 
I was asked by the snappy team to have base snaps trigger a manual review for now. There is a mechanism to whitelist base snaps that are deemed ok to let through. @zyga-snapd is right that we have no formal processes or criteria yet for approving them, partly because, AIUI, the feature isn’t considered complete yet.
@niemeyer - can you comment on what the process might be and specifically on this snap?
FWIW I would agree that the initial introduction of any new “base” provider should likely be vetted - after all this isn’t docker hub 
@jdstrand @ikey Can we have a call about this at some point in the next few days?
Indeed this is new ground, and while we’ll definitely see this snap approved in some fashion, I’d like to explore the problems we need to watch out for and what our solutions for these will be.
The most obvious problem I can think of is that this is of course a one-level dependency, and so anyone publishing such snaps needs to understand and agree to preserve a stable API, virtually forever, otherwise every single snap that will be built upon it will be broken.
Then, we probably need to establish some practices to help precisely on that. At the very least some kind of version number is probably needed, as the content inside the snap will naturally evolve into new APIs and ABIs as time passes.
Anyway, that’s just some seed ideas. Can we please meet to talk about this?
Uhm, that’s not gonna happen . The base snap is derived from Solus which is a rolling release, and is provided purely to satisfy the needs of a single snap, linux-steam-integration. The ABI will mutate over time. Perhaps what is needed then is the distinction of derivable in a base snap. Also I’m slightly concerned that we don’t expect descendant snaps to be built in response to alterations in the parent - personally I believe that all snaps should be required to be rebuilt at a fixed period to ensure that they can still build - We should avoid rot by design.
Anyways, I have some ideas myself about coupling base snaps with abireport so that each published version of the snap would also track the full system ABI. Happy to discuss this over a call (hangouts, maybe? :)) just lemme knoiw.
We do need stability in base snaps. There’s just no way we can encourage people to build their own snaps upon a base that can break their snap tomorrow or the day after.
Let’s catch up via a hangout as the better bandwidth will make it much easier to align and find a solution that works on all ends.
@jdstrand Can you join us today?
So I think to capture the important items…
Technically this base snap is more a middle ground between content and base, a kind of root. It only really exists to satisfy the rootfs conditions for linux-steam-integration, and building against it is not recommended for two main reasons:
/usr/lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.12.Thus it isn’t really feasible to use snapcraft to produce snaps against our runtime unless already on a Solus host. My thoughts in this regard is actually teaching ypkg and solbuild to produce snaps. Ideally they’d use a similar entry point to linux-steam-integration (C Binary) for environment bootstrap and bundle the accompanying libraries. As their final step they’d call out to snap pack. Once we’re at that point we would produce a general purpose runtime for Solus snaps (akin to core) and ensure solbuild works on all hosts. We just got it working on Manjaro so we can definitely port to Ubuntu as a static binary.
For now, the agreement is that solus-runtime-gaming is non-derivable and a warning should be emitted for anyone else trying to derive from it. We’ll begin working proper CI processes into the production of the runtime to set somewhat of an example, generating ABI Reports on each build to account for any soname or ABI differences in that build (ideally they shouldn’t impact consumers!) and begin versioning the snaps from the Solus version.
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:
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.
Note that this, in particular, is not something special about Solus or its base snaps. There are known incompatibilities across distributions in those terms, and this will be true even across versions of the same distribution. Tolerating that sort of difference is one of the important reasons why base snaps were introduced.
Was merely pointing out one of many base incompatibilities to point out why it is deeply inappropriate to use the wrong toolchain to build for Solus when we have an architecture in place that allows native builds and relocations.
Update: Now tracking ABI here: https://github.com/solus-project/runtime-snaps/tree/master/abi
Note the symbol files are around 5MB each so won’t open on GitHub viewer, only raw (it has a link)
Right now fixing some last straggler libs (we shouldn’t have abi_used_libs files if all dependencies are satisfied)
Versioning for runtime set to 3.0.0 to derive from Solus versioning
Reading backscroll, here are the takeaways AIUI, please correct me as necessary:
‘1’ and ‘2’ seem reasonable to me as a reviewer.
For ‘3’, I’ve approved r8 of the solus-runtime-gaming snap. I have updated the review-tools so subsequent uploads will not trigger a manual review, but this change is not yet in production so please ping me for new uploads until it is.
For ‘4’, I’ll implement this test in the review-tools. It might be nice if base snaps had the concept of ‘from the same publisher’ like we express in the content interface base declaration.
‘5’ is a little tricky in that the review tools don’t have state and so while it can generate symbols files for libs in the snap, it has nothing to compare those to so store side work is required to run something (eg, the review tools) to obtain the symbols for a particular snap, to store that in the db, then to give that back to the review tools on the next review (eg, snap-review --previous-symbols=/path/to/foo base.snap). I’ve taken this as a longer term TODO for the review tools.
It is interesting to think about snapcraft generating a symbols file in the snap in a known location, similar to how it will be generating a build manifest file. This is handy for developers and would simplify the store abi checking code a bit.
This is done. It’ll be a little bit before it hits production.
Thanks for the nice summary, Jamie, and for working on these items.
On point 4, indeed that’s something that’s still on the table.
For point 5, we discussed this before, and we even had an item pretty high up in the store roadmap at some point to implement that sort of state tracking. We should probably restart those discussions so we can eventually have this. Should be easy to have a json document that is provided to the review tools and collected back when done.