Sugar Network/Recipe Specification: Difference between revisions

Line 1:

Read the [[Platform_Team/Guide/Sweets_Packaging|Packaging Guide]] to ~~know~~ to write and use recipe files.

Read the [[Platform_Team/Guide/Sweets_Packaging|Packaging Guide]] to learn how to write and use recipe files.

== Use case sections ==

~~Recipe~~ should contain at least one use case section to describe how the sweet might be used.

A recipe should contain at least one use case section to describe how the sweet might be used.

Use case sections are named:

Line 9:

[''use-case-type''[:''sub-name'']]

Where ''use-case-type'' is one of the following sub sections and ''sub-name'' is an optional identifier used if there are more than one ~~sections~~ of the same type.

Where ''use-case-type'' is one of the following sub sections and ''sub-name'' is an optional identifier used if there are more than one section of the same type.

Regardless of the type, a use case section (or one of them) should contain the following options.

Line 17:

'''implement''' = <sweet> [; ...]

Required. The list of interfaces that current project is implementing.

Required. The list of interfaces that the current project is implementing.

'''associate''' = <sweet> [; ...]

Optional. The list of interfaces whose implementations might be considered as additional implementations for current one.

Optional. The list of interfaces whose implementations might be considered as additional implementations for the current one.

'''name''' = <name>

Line 53:

'''tags''' = <tag> [; ...]

Optional. Tags give more context in which to group the sweet. This is ~~used~~ to allow users to find sweets more easily.

Optional. Tags give more context by which to group the sweet. This is done to allow users to find sweets more easily.

'''version''' = <version-number>

Line 94:

'''requires''' = <dependency> [(=|>=|<) <version>] [; ...]

Optional. List of [[Platform_Team/Guide/Packaging#Package_names|dependencies]] that should exist in run-time before launching the activity.

Optional. List of [[Platform_Team/Guide/Packaging#Package_names|dependencies]] that should exist at run-time before launching the activity.

=== [Application] ===

Application to run ~~out~~ of Sugar Shell.

Application to run outside of Sugar Shell.

'''exec''' = <shell-command>

Line 106:

'''requires''' = <dependency> [(=|>=|<) <version>] [; ...]

Optional. List of [[Platform_Team/Guide/Packaging#Package_names|dependencies]] that should exist in run-time before launching the application.

Optional. List of [[Platform_Team/Guide/Packaging#Package_names|dependencies]] that should exist at run-time before launching the application.

=== [Library] ===

Line 120:

=== [Package] ===

This is a special section that does not relate to sweets directly and mentioned here only for recipe specification completeness. Using this section turns a recipe to some kind of meta-distribution spec file on OBS. The important things need to be kept in mind in ~~that~~ case:

This is a special section that does not relate to sweets directly and is mentioned here only for recipe specification completeness. Using this section turns a recipe to some kind of meta-distribution spec file on OBS. The important things that need to be kept in mind in this case are these:

* it is very limited by design in ~~comparing~~ with regular GNU/Linux distribution spec files;

* it is very limited by design in comparison with regular GNU/Linux distribution spec files;

* there are no any intentions to follow meta-distribution ~~way~~;

* there are not any intentions to follow this meta-distribution method;

* the ~~major~~ distribution ~~way~~ for sweets is using 0install, i.e., not using ''[Package]'' section, thus, native packages at all;

* the primary distribution method for sweets is using 0install, i.e., not using the ''[Package]'' section, thus, native packages, at all;

* this section was introduced only for cases when having native packages makes sense, e.g., for Live Sugar distributions or LTSP.

In addition to already [[#Predefined_options|~~existed~~]] predefined options, there are several new defines that make sense only for this section packages:

In addition to the already [[#Predefined_options|existing]] predefined options, there are several new defines that make sense only for this section's packages:

* {{Code|EXEC_PREFIX}}

Line 156:

'''conflicts''' = <native-package-name> [; ...]

Optional. The list of native packages, i.e., names from particular GNU/Linux distribution, that conflict with the sweet based package and cannot be installed at the same time.

Optional. The list of native packages, i.e., names from a particular GNU/Linux distribution, that conflict with the sweet based package and cannot be installed at the same time.

'''install''' = <shell-command>

Optional. The command that will be executed after installing binary package composed from this recipe.

Optional. The command that will be executed after installing the binary package composed from this recipe.

'''uninstall''' = <shell-command>

Optional. The command that will be executed after uninstalling binary package composed from this recipe.

Optional. The command that will be executed after uninstalling the binary package composed from this recipe.

== Archive sections ==

~~Archive~~ section describes the tarball that will contain the sweet implementation.

An archive section describes the tarball that will contain the sweet implementation.

If there are not any archive sections, the sweet implementation consists of only one archive that includes the entire {{Code|%(DESTDIR)s}} directory (excluding temporary files). At the same time, the sweet implementation might be split into several archives.

Line 241:

'''exclude''' = <glob-pattern> [; ...]

Optional. If the ''exec'' option was not used, all files will be bundled and these [[Platform_Team/Guide/Packaging#Glob patterns|glob patterns]] might be used to ~~concretize~~ the selection.

Optional. If the ''exec'' option was not used, all files will be bundled and these [[Platform_Team/Guide/Packaging#Glob patterns|glob patterns]] might be used to reify the selection.

'''requires''' = <dependency> [(=|>=|<) <version>] [; ...]

@@ Line 1: / Line 1: @@
-Read the [[Platform_Team/Guide/Sweets_Packaging|Packaging Guide]] to know to write and use recipe files.
+Read the [[Platform_Team/Guide/Sweets_Packaging|Packaging Guide]] to learn how to write and use recipe files.
 == Use case sections ==
-Recipe should contain at least one use case section to describe how the sweet might be used.
+A recipe should contain at least one use case section to describe how the sweet might be used.
 Use case sections are named:
@@ Line 9: / Line 9: @@
   [''use-case-type''[:''sub-name'']]
-Where ''use-case-type'' is one of the following sub sections and ''sub-name'' is an optional identifier used if there are more than one sections of the same type.
+Where ''use-case-type'' is one of the following sub sections and ''sub-name'' is an optional identifier used if there are more than one section of the same type.
 Regardless of the type, a use case section (or one of them) should contain the following options.
@@ Line 17: / Line 17: @@
   '''implement''' = <sweet> [; ...]
-Required. The list of interfaces that current project is implementing.
+Required. The list of interfaces that the current project is implementing.
   '''associate''' = <sweet> [; ...]
-Optional. The list of interfaces whose implementations might be considered as additional implementations for current one.
+Optional. The list of interfaces whose implementations might be considered as additional implementations for the current one.
   '''name''' = <name>
@@ Line 53: / Line 53: @@
   '''tags''' = <tag> [; ...]
-Optional. Tags give more context in which to group the sweet. This is used to allow users to find sweets more easily.
+Optional. Tags give more context by which to group the sweet. This is done to allow users to find sweets more easily.
   '''version''' = <version-number>
@@ Line 94: / Line 94: @@
   '''requires''' = <dependency> [(=|>=|<) <version>] [; ...]
-Optional. List of [[Platform_Team/Guide/Packaging#Package_names|dependencies]] that should exist in run-time before launching the activity.
+Optional. List of [[Platform_Team/Guide/Packaging#Package_names|dependencies]] that should exist at run-time before launching the activity.
 === [Application] ===
-Application to run out of Sugar Shell.
+Application to run outside of Sugar Shell.
   '''exec''' = <shell-command>
@@ Line 106: / Line 106: @@
   '''requires''' = <dependency> [(=|>=|<) <version>] [; ...]
-Optional. List of [[Platform_Team/Guide/Packaging#Package_names|dependencies]] that should exist in run-time before launching the application.
+Optional. List of [[Platform_Team/Guide/Packaging#Package_names|dependencies]] that should exist at run-time before launching the application.
 === [Library] ===
@@ Line 120: / Line 120: @@
 === [Package] ===
-This is a special section that does not relate to sweets directly and mentioned here only for recipe specification completeness. Using this section turns a recipe to some kind of meta-distribution spec file on OBS. The important things need to be kept in mind in that case:
+This is a special section that does not relate to sweets directly and is mentioned here only for recipe specification completeness. Using this section turns a recipe to some kind of meta-distribution spec file on OBS. The important things that need to be kept in mind in this case are these:
-* it is very limited by design in comparing with regular GNU/Linux distribution spec files;
+* it is very limited by design in comparison with regular GNU/Linux distribution spec files;
-* there are no any intentions to follow meta-distribution way;
+* there are not any intentions to follow this meta-distribution method;
-* the major distribution way for sweets is using 0install, i.e., not using ''[Package]'' section, thus, native packages at all;
+* the primary distribution method for sweets is using 0install, i.e., not using the ''[Package]'' section, thus, native packages, at all;
 * this section was introduced only for cases when having native packages makes sense, e.g., for Live Sugar distributions or LTSP.
-In addition to already [[#Predefined_options|existed]] predefined options, there are several new defines that make sense only for this section packages:
+In addition to the already [[#Predefined_options|existing]] predefined options, there are several new defines that make sense only for this section's packages:
 * {{Code|EXEC_PREFIX}}
@@ Line 156: / Line 156: @@
   '''conflicts''' = <native-package-name> [; ...]
-Optional. The list of native packages, i.e., names from particular GNU/Linux distribution, that conflict with the sweet based package and cannot be installed at the same time.
+Optional. The list of native packages, i.e., names from a particular GNU/Linux distribution, that conflict with the sweet based package and cannot be installed at the same time.
   '''install''' = <shell-command>
-Optional. The command that will be executed after installing binary package composed from this recipe.
+Optional. The command that will be executed after installing the binary package composed from this recipe.
   '''uninstall''' = <shell-command>
-Optional. The command that will be executed after uninstalling binary package composed from this recipe.
+Optional. The command that will be executed after uninstalling the binary package composed from this recipe.
 == Archive sections ==
-Archive section describes the tarball that will contain the sweet implementation.
+An archive section describes the tarball that will contain the sweet implementation.
 If there are not any archive sections, the sweet implementation consists of only one archive that includes the entire {{Code|%(DESTDIR)s}} directory (excluding temporary files). At the same time, the sweet implementation might be split into several archives.
@@ Line 241: / Line 241: @@
   '''exclude''' = <glob-pattern> [; ...]
-Optional. If the ''exec'' option was not used, all files will be bundled and these [[Platform_Team/Guide/Packaging#Glob patterns|glob patterns]] might be used to concretize the selection.
+Optional. If the ''exec'' option was not used, all files will be bundled and these [[Platform_Team/Guide/Packaging#Glob patterns|glob patterns]] might be used to reify the selection.
   '''requires''' = <dependency> [(=|>=|<) <version>] [; ...]