This is missing the service ordering parts which are already documented for The snap format .
Name
Description
apps. <app-name>. before optional
List of applications that are ordered to be started before <app-name>. Applications must be part of the same snap. (snapd 2.31+) Type:list[string] Requires daemon to be set as the app type.
apps. <app-name>. after optional
List of applications that are ordered to be started after <app-name>. Applications must be part of the same snap. (snapd 2.31+) Type:list[string] Requires daemon to be set as the app type.
It would be nice if this document talked about the /root/parts/<part-name>/* subdirectories where relevant.
For example, parts.<part-name>.organize says A map of files to rename / the key represents the path of a file inside the part and the value represents how the file is going to be staged.
But if I shell into the build container and go to /root/parts/<part-name>/, I see these subdirectories:
build
install
run
src
state
Does organize copy/rename those files from src to build? From src to install? From build to install?
Similarly, does parts.<part-name>.stage copy files from build to install? Or install to /root/stage? Does parts.<part-name>.prime only copy from /root/stage to /root/prime, or does it get involved in /root/parts/<part-name>/ somehow?
The context that Iād like to know all of this is that if I use say override-build and then run snapcraftctl build, Iām left unsure what steps have been run, and where the files have been put (build or install or /root/stage/?).
It would also be great if sections like parts.<part-name>.override-build could talk about what exactly snapcraftctl build does. IIRC, it handles running parts.<part-name>.organize, so if you donāt run snapcraftctl build for whatever reason, the files donāt get organized.
Why do we need to edit the documentation in such a strange way instead of editing some md file on github?
I donāt see any benefits in this approach, and many issues, like polluting this chat and needing to reference āwhere the section says X and Y it actually should beā¦ā. I mean, this definitely doesnāt scale in the long term and seem to just become more and more confusing
I completely agree that this is not a suitable way to collaborate on docs, and. Iāve raised this as an issue both before and after the implementation. It seems that itās the way that Canonical has decided to do things despite being unworkable/unscalable. Similarly the Ubuntu Discourse does the same thing for tutorials and docs specific to Ubuntu, also. Whenever Iāve raised this issue it has been stated that itās fine and wonāt be changing.
Yes, of course - thanks for letting me know. Iāll update this post when itās done.
Update: Iāve added Layout to the above reference and also to the top-level metadata document. I think we missed this because layouts had been experimental for so long.
The information for āadopt-infoā WRT snapcraft 7 seems incomplete. This page states that only āversionā is a mandatory field that can be assigned via āadopt-infoā. However, consider the source here:
So it seems that āadopt-infoā is associated with, at a minimum, grade, version, summary and/or description. Can this be clarified?