Sugar Network/Recipe Specification: Difference between revisions

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

Use ''recipe'' option to declare a service as a recipe:

   [Service]

Only the following options make sense for component sections, and they cannot be used in the recipe section. Other options that the recipe component section will inherit from the recipe section:

The same component could a part of different recipes. In that case, different (sub)service implementations will contain the same component tarball.

The final ''[Service]'' implementation will contain 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 ''[binary]'' section and one common for both implementations ''[data]'' tarball.

  [Service]

  include = share/*

  include = bin/*, lib/*