| Line 1: |
Line 1: |
| − | [[Category:Zero Sugar]]
| + | {{Draft}} |
| | | | |
| | == Writing recipe files == | | == Writing recipe files == |
| Line 44: |
Line 44: |
| | * ''**'' matches everything, including directory separator | | * ''**'' matches everything, including directory separator |
| | | | |
| − | === Sub packages === | + | === Multiple components === |
| | | | |
| − | By default, package is the singular and will be composed using ''[Package]'' or/and ''[Activity]'' sections. But if the package contains several logical components, it might have sub packages. In that case, the recipe file should contain additional sections (per sub package) in the form:
| + | The sweet distribution might be split into several tarballs that can be composed in different ways when the same sweet release contains several implementations with different tarballs compositions. Possible use cases: |
| | | | |
| − | [Package/<nowiki><sub-package></nowiki>]
| + | * To save storage space or bandwidth when some tarballs will contain any-arch data that are common for all platforms and another tarball will contain binaries for a particular platform. |
| | + | * ''TODO''. |
| | | | |
| − | Formatting of sub sections is identical to the ''[Package]'' section. Sub packages could make sense, e.g., for packaging additional content, or to separate a library and its script language binding.
| + | Additional components need to be placed to different sections with the same options as ''[Component]'' has: |
| | | | |
| − | Other packages can mention sub packages by the format:
| + | [Component/<nowiki><name></nowiki>] |
| − | | |
| − | <package>/<nowiki><sub-package></nowiki>
| |
| − | | |
| − | Good practise is using the following names for sub packages:
| |
| − | | |
| − | * ''python'' for Python binding,
| |
| − | * ''standalone'' if package might be used not only as a Sugar activity but also as a regular application (also, the [[Platform_Team/Recipe_Specification#.5BActivity.5D|Activity]] preset could be used for such sub packages).
| |
| − | | |
| − | === Bundles ===
| |
| − | | |
| − | In some cases, e.g., to save storage space or bandwidth, it is useful to split a packaged application into several tarballs when some tarballs will contain any-arch data that are common for all platforms and another tarball will contain binaries for a particular platform. Thus, if an application supports several platforms, and any-arch data is big (multiple media, text, etc. files), duplicate tarballs are avoided.
| |
| − | | |
| − | The key differences between bundles and sub packages:
| |
| − | * Sub packages are logically independent parts of the package; bundles make sense only to save storage space;
| |
| − | * Each sub package is identified by a unique 0install url; all bundle components are identified by the same url;
| |
| − | * Tarballs for different sub packages will be extracted to different directories; bundle component tarballs, within the same bundle, will be extracted to the same directory.
| |
| − | | |
| − | Use the ''bundle'' option to declare a (sub)package(s) as a bundle:
| |
| − | | |
| − | [Package]
| |
| − | bundle = <bundle-component-name> [; ...]
| |
| − | | |
| − | and declare sections that contain components:
| |
| − | | |
| − | [<component-name>]
| |
| − | ...
| |
| − | | |
| − | Bundle component sections can contain only files-related options such as ''include'', ''exclude'', ''arch'', and ''langs''.
| |
| − | | |
| − | The same component could be a part of different bundles. In that case, the different package implementations will contain the same bundle component tarball.
| |
| | | | |
| | == Pitfalls == | | == Pitfalls == |