Sugar Network/Recipe Specification: Difference between revisions

Line 275:

== Recipes ==

In some cases, e.g., to save storage space or bandwidth, it is useful to split a packaged application into several ~~parts~~ when some ~~parts~~ will ~~be common. The most usual case is having~~ any-arch data and binaries ~~sub-packages, i.e~~., ~~the final service will depend on a data sub-package (one implementation per~~ application ~~release)~~ and ~~sub~~-~~packages with binaries~~ (~~implementations per arch per application release~~). ~~But it's not possible to always use~~ sub-packages~~. Applications could assume that data is placed in a particular relative path from~~ the ~~launched binaries, and if there~~ is ~~no way to set data location via environment bindings~~, sub-packages ~~are useless and recipes~~ will ~~help~~.

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 other will contain binaries for particular platform. Thus, if an application supports several platforms and any-arch data is big (various media, text, etc. files), there will not be duplicate tarballs.

The key differences between recipes and sub packages:

* Sub packages are logically independent parts of the package;

* Each sub package is identified by unique 0install url, all recipe components are identified by recipe url;

* Tarballs for different sub packages will be extracted to different directories, recipe component tarballs, within the same recipe, will be extracted to the same directory.

Use the ''recipe'' option to declare a (sub)package(s) as a recipe:

Line 289:

Line 294:

Being a recipe, the package section cannot contain files-related options (since package itself does not contain any tarballs directly, only via recipe components), these options could be set only in components:

* root

* langs

* arch

* include

* exclude

* main

* exec

* slots

The same component could be a part of different recipes. In that case, different package implementations will contain the same recipe component tarball.

The final package implementation will contain a tarball per component. All these tarballs will be unpacked to the same root directory. For example, having the following lines and invoking ''0sugar build'' on two platforms - x86 and x86_64 platforms, two (per-arch) implementations will be created and they will use three tarballs - x86 and x86_64 tarballs from the ''[binary]'' section, and one common ''[data]'' tarball for both implementations.

~~[Package]~~

~~recipe = data, binary~~

~~[data]~~

include = share/**

~~[binary]~~

include = bin/**, lib/**

~~main = bin/launch~~

~~arch = build~~

== Slots ==

@@ Line 275: / Line 275: @@
 == Recipes ==
-In some cases, e.g., to save storage space or bandwidth, it is useful to split a packaged application into several parts when some parts will be common. The most usual case is having any-arch data and binaries sub-packages, i.e., the final service will depend on a data sub-package (one implementation per application release) and sub-packages with binaries (implementations per arch per application release). But it's not possible to always use sub-packages. Applications could assume that data is placed in a particular relative path from the launched binaries, and if there is no way to set data location via environment bindings, sub-packages are useless and recipes will help.
+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 other will contain binaries for particular platform. Thus, if an application supports several platforms and any-arch data is big (various media, text, etc. files), there will not be duplicate tarballs.
+The key differences between recipes and sub packages:
+* Sub packages are logically independent parts of the package;
+* Each sub package is identified by unique 0install url, all recipe components are identified by recipe url;
+* Tarballs for different sub packages will be extracted to different directories, recipe component tarballs, within the same recipe, will be extracted to the same directory.
 Use the ''recipe'' option to declare a (sub)package(s) as a recipe:
@@ Line 289: / Line 294: @@
 Being a recipe, the package section cannot contain files-related options (since package itself does not contain any tarballs directly, only via recipe components), these options could be set only in components:
-* root
 * langs
 * arch
 * include
 * exclude
-* main
 * exec
 * slots
 The same component could be a part of different recipes. In that case, different package implementations will contain the same recipe component tarball.
-The final package implementation will contain a tarball per component. All these tarballs will be unpacked to the same root directory. For example, having the following lines and invoking ''0sugar build'' on two platforms - x86 and x86_64 platforms, two (per-arch) implementations will be created and they will use three tarballs - x86 and x86_64 tarballs from the ''[binary]'' section, and one common ''[data]'' tarball for both implementations.
- [Package]
- recipe = data, binary
- [data]
- include = share/**
- [binary]
- include = bin/**, lib/**
- main = bin/launch
- arch = build
 == Slots ==