Platform Team/Guide/Sweets Packaging: Difference between revisions

Line 47:

[Package/<nowiki><sub-package></nowiki>]

~~Format~~ of sub sections is identical to ''[Package]'' section. Sub packages could make sense, e.g., for packaging additional content, or to separate library and its script language binding.

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.

Other packages can mention sub packages by the format:

Line 60:

=== Recipes ===

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.

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 recipes and sub packages:

* Sub packages are logically independent parts of the package, recipes make sense only to save storage space;

* Sub packages are logically independent parts of the package; recipes make sense only to save storage space;

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

* Each sub package is identified by a unique 0install url; all recipe components are identified by a 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.

* 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 77:

...

Recipe component sections can contain only files related options such as ''include'', ''exclude'', ''arch'' and ''langs''.

Recipe component sections can contain only files-related options such as ''include'', ''exclude'', ''arch'', and ''langs''.

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

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

=== Slots ===

@@ Line 47: / Line 47: @@
    [Package/<nowiki><sub-package></nowiki>]
-Format of sub sections is identical to ''[Package]'' section. Sub packages could make sense, e.g., for packaging additional content, or to separate library and its script language binding.
+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.
 Other packages can mention sub packages by the format:
@@ Line 60: / Line 60: @@
 === Recipes ===
-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.
+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 recipes and sub packages:
-* Sub packages are logically independent parts of the package, recipes make sense only to save storage space;
+* Sub packages are logically independent parts of the package; recipes make sense only to save storage space;
-* Each sub package is identified by unique 0install url, all recipe components are identified by recipe url;
+* Each sub package is identified by a unique 0install url; all recipe components are identified by a 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.
+* 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 77: / Line 77: @@
    ...
-Recipe component sections can contain only files related options such as ''include'', ''exclude'', ''arch'' and ''langs''.
+Recipe component sections can contain only files-related options such as ''include'', ''exclude'', ''arch'', and ''langs''.
-The same component could be a part of different recipes. In that case, different package implementations will contain the same recipe component tarball.
+The same component could be a part of different recipes. In that case, the different package implementations will contain the same recipe component tarball.
 === Slots ===