Agreements about base snaps from the first morning:
also click/snap-review-tools need updating to support base snaps
might need a bootable flag in the base snap.yaml to indicate whether a base snap can be used as boot base snap for a device (from the model)
Agreement about AppStream from after lunch on Monday:
- Snapcraft will have a means of populating the snap.yaml with data from the AppStream yaml, setup.py, etc
- Snapcraft will write appstream.yaml next to snap.yaml
- Appstream.yaml has a small set of fields not in snap.yaml
- Fields going in to appstream.yaml are agreed on by desktop/snapd teams
- Snapcraft uploads screenshots via new endpoint going into the same place
- Store keeps appstream.yaml in database as blob or JSON/fields (TBD)
- Snapd returns appstream.yaml as JSON or blob (tbd)
- GNOME Software will continue to work with snaps without appstream data
Board from meeting @willcooke just mentioned above:
Agreements about the session on snap layouts just now (previously known as “overmounts”).
Updates from Tuesday:
- New syntax that reflects the idea of “layout” better
- New user, group, and mode fields
Preliminary ideas about user ID mappings.
Updates from Tuesday:
- snap.yaml must define what users and groups it depends upon
- We want snap devices to see “nobody” instead of “snap_nobody”
The following agreements were made about GUI-related needs this morning.
We also had a long discussion about representing interfaces in gnome-software, and have not yet managed to find a clear path towards making it acceptable for upstream.
Updated some of the posts above with conversations from this morning. They also got updated whiteboard pictures.
Agreements about validation improvements from this afternoon:
And then about epochs (stepped updates):
Preliminary agreements about improved theme support below. More needs to be discussed for something to be implementable.
Quick sketch about how the “double starred” epochs enable transition of data forward without preventing reverts to prior revision:
snapd must ensure that once a revision lacking a double starred epoch is installed, the double star behavior is disabled and going back an epoch is not possible anymore, even if a revert into the double starred revision happens. This is necessary because the double star is what tells the system that compatibility is still being preserved.
Agreements about the upcoming improvements for the kernel and gadget snaps that will enable image resources to be updated (top) and avoid the need of lockstep updates in the Raspberry Pi (bottom).
Agreements about how the management of textual information (summary, description, translations, etc) will take place between snapcraft and store:
Regarding the metadata/textual info, I think we also need a snapcraft command to sync from the store to the local snapcraft.yaml. So if you are a developer of a snap where the text is always edited in the store UI (possible a different person in your team), you can do something like
snapcraft update-text --from-store && snapcraft && snapcraft push in your CI to ensure that builds always have the latest info inside the snap.
You would also want to periodically update the snapcraft.yaml and commit to your repo, but that could be just part of your local dev workflow.