I know build-snaps is in the works. How about stage-snaps (so build-snaps is kinda build-packages for snaps rather than Debs (I think?) and stage-snaps would be stage-packages for snaps rather than Debs)?
This would be useful so that the GNOME content snaps (for example) could be automatically installed and then automatically connected, which would mean one line install for apps that use them. At the moment, two lines are needed (three if there’s no auto-connection for the content snap in question).
I understand that snappy devs don’t particularly want to go back to the old dependencies system, where updates to dependencies risk breaking the apps that depend on them(?), however, with snappy, because you can bundle dependencies, reverting to bundling your own dependency is possible. E.g. if something in the GNOME content snap broke Corebird and it weren’t easy to fix the issue in the GNOME content snap, @lucyllewy could, in theory, revert Corebird to bundling it’s own dependencies for the time being. Perhaps, if stage-snaps were powerful enough, Daniel could even specify an earlier (working) revision of the GNOME content snap to be used. In this particular example, the GNOME content snaps currently have different names depending on GNOME version and the Ubuntu stack used, so not much breakage should occur anyway.
But I’m just a random enthusiast, I hope that this could be considered and a better proposal by a expert created and that the snappy team has time to create this. I think that such a feature would make snaps easier to use - the objective should be one line install for every app (without compromising on security).
Perhaps it is already possible to have content snaps installed by other apps without another line of Terminal required? Maybe someone could inform me of that. Thanks! 
2 Likes
Hi, suggestions are always welcome.
It seems there are two things to solve or proposed here:
- the
stage-snaps equivalent of stage-packages.
- Snaps switching mid road to using the
content interface seem to unexpectedly break.
There is a proposal in between the lines that using stage-snaps would solve this, but it would not be any different than what you would be able to do today with the current stage-packages anyways. As soon as you stage something with whatever mechanism you are plastering, for eternity, what a snap revision holds.
Now, onto stage-snaps, the work to enable this is super easy but I’d like to wait on it as the mental model might not be ok at this point and the place where build-snaps are useful are those which have a hard requirement on relocation (so waiting on layouts would be best here). In summary, from a snapcraft standpoint, this is super easy work but making a nice story out of it would need some more time.
The latter item about the content interface is a snapd feature (to be developed), where the system would try to connect (in case of autoconnect), the default slot on the host system and if not obtain the default snap providing a slot from the snap store. Some of this is what @zyga-snapd used to work on so he might have more, but I would suggest to branch of this into a new forum topic so the conversation doesn’t get lost in the future.
2 Likes
I’ve already written something that will allow you to use a snap as the source in a snapcraft part, which combined with the dump plugin would effectively give you a stage-snaps capability.
However it does cause quite a lot of file conflicts when trying to combine parts into the stage directory, because both the source snap part and your app’s part will just about always have some of the same bundled files from dependencies that your other parts are using, and I couldn’t find a good, clean, reliable way of stripping them out. At the time there was no snapcraft manifest data in the resulting snaps that could be used to determine when those conflicts could be ignored, but I recall hearing that such a manifest might be included at some point.
2 Likes
I’m guessing that would be this GH Issue and this design post?
1 Like
