Sugar Network/Recipe Specification: Difference between revisions

Line 5:

Recipe file is an [http://docs.python.org/library/configparser.html ini] format configuration file that might consist of several sections:

* ~~Component sections:~~

* One or more [[#Component sections|component sections]].

** [[#~~Main component~~|~~Main~~ component]] ~~section,~~

** Optional [[#Extra_components|extra component]] sections.

* Optional auxiliary sections:

** [[#.5BBuild.5D|[Build]]],

Line 13:

Line 11:

* Optional {{Code|[DEFAULT]}} section with common options that are accessible from all other sections.

== ~~Recipe components~~ ==

== Component sections ==

~~The sweet distribution contains~~ one ~~or several tarballs. Each tarball is being described by~~ component section.

Recipe should contain at least one component section. Component sections describe how the sweet might be used and can be one of [[#Component_types|predefined types]].

~~=== Main component ===~~

Component sections are named:

~~This is a required section with the name:~~

<nowiki>[</nowiki>[[#Component_types|type]]<nowiki>]</nowiki>

Component types like [[#.5BApplication.5D|Application]] and [[#.5BComponent.5D|Component]] might have several sections, in that case, they need to be named as:

<nowiki>[</nowiki>[[#Component_types|type]]/''subname''<nowiki>]</nowiki>

where {{Code|subname}} is a meaningful name that will be used, e.g., in native packages names.

=== Common component options ===

Regardless of the type, ~~it contains~~ followed options:

Regardless of the type, component section (or one of them) should contain followed options:

'''sweet''' = <identifier>

Line 100:

Line 104:

* ''all'' for noarch (by default)

* ''any'' for binaries to use the current architecture

~~=== Extra components ===~~

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. Each component section (including [[#Main component|main]] one) describes one of these tarballs.

~~Possible use cases:~~

* 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''.

~~Extra component sections should be named:~~

~~<nowiki>[</nowiki>[[#Component_types|type]]/''name''<nowiki>]</nowiki>~~

== Component types ==

Line 162:

Line 154:

The environment variables 0install should export to the process that uses this package. This makes sense only for multiple-activity-serving dependencies (like libraries), not for the activity itself.

=== [Component] ===

The sweet distribution might be split into several tarballs when the same sweet release contains several implementations with different tarballs compositions.

Possible use cases:

* 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.

* If content is multilingual and big, to avoid needless downloads on user side, tarballs might be formed per language.

* Having optional content that will be downloaded only for particular cases.

Such tarballs are described by {{Code|[Component]}} sections.

== Auxiliary sections ==

@@ Line 5: / Line 5: @@
 Recipe file is an [http://docs.python.org/library/configparser.html ini] format configuration file that might consist of several sections:
-* Component sections:
+* One or more [[#Component sections|component sections]].
-** [[#Main component|Main component]] section,
-** Optional [[#Extra_components|extra component]] sections.
 * Optional auxiliary sections:
 ** [[#.5BBuild.5D|[Build]]],
@@ Line 13: / Line 11: @@
 * Optional {{Code|[DEFAULT]}} section with common options that are accessible from all other sections.
-== Recipe components ==
+== Component sections ==
-The sweet distribution contains one or several tarballs. Each tarball is being described by component section.
+Recipe should contain at least one component section. Component sections describe how the sweet might be used and can be one of [[#Component_types|predefined types]].
-=== Main component ===
+Component sections are named:
-This is a required section with the name:
+ <nowiki>[</nowiki>[[#Component_types|type]]<nowiki>]</nowiki>
-  <nowiki>[</nowiki>[[#Component_types|type]]<nowiki>]</nowiki>
+Component types like [[#.5BApplication.5D|Application]] and [[#.5BComponent.5D|Component]] might have several sections, in that case, they need to be named as:
+  <nowiki>[</nowiki>[[#Component_types|type]]/''subname''<nowiki>]</nowiki>
+where {{Code|subname}} is a meaningful name that will be used, e.g., in native packages names.
+=== Common component options ===
-Regardless of the type, it contains followed options:
+Regardless of the type, component section (or one of them) should contain followed options:
   '''sweet''' = <identifier>
@@ Line 100: / Line 104: @@
 * ''all'' for noarch (by default)
 * ''any'' for binaries to use the current architecture
-=== Extra components ===
-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. Each component section (including [[#Main component|main]] one) describes one of these tarballs.
-Possible use cases:
-* 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''.
-Extra component sections should be named:
- <nowiki>[</nowiki>[[#Component_types|type]]/''name''<nowiki>]</nowiki>
 == Component types ==
@@ Line 162: / Line 154: @@
 The environment variables 0install should export to the process that uses this package. This makes sense only for multiple-activity-serving dependencies (like libraries), not for the activity itself.
+=== [Component] ===
+The sweet distribution might be split into several tarballs when the same sweet release contains several implementations with different tarballs compositions.
+Possible use cases:
+* 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.
+* If content is multilingual and big, to avoid needless downloads on user side, tarballs might be formed per language.
+* Having optional content that will be downloaded only for particular cases.
+Such tarballs are described by {{Code|[Component]}} sections.
 == Auxiliary sections ==